Proposal: Improved integration with setuptools

[afshin]

Problem

We want to support a build step for Python packages that gets invoked under the following scenarios:

• python setup.py sdist
• python setup.py bdist_wheel
• python -m build .
• pip install -e . (less important)
• pip install .
• pip install git+https://github.com/foo/bar

Until or unless flit supports glob patterns for data_files and a build step, the best thing to do is still extend setuptools. enscons adds too much of a burden on maintainers, who would need to add an SConstruct file and learn SCons.

Solution

Embrace and more cleanly extend setuptools.

• We recommend that people use MANIFEST.in and include_package_data to manage the files that will be included in releases. Then we can drop package_data handling and internal handling of data_files.
• We recommend check-manifest to replace ensure_targets
• We recommend using version = attr: foo.__version__ setup.cfg. Note: setuptools does not yet support pyproject.toml metadata.
• We drop support for data_files in develop mode since the data files cannot be uninstalled. We provide a get_data_files function but recommend people use setup.cfg for non-glob-pattern data files.
• We have three main functions:
  • wrap_installers takes a pre or post build functions to run and returns something suitable for a cmdclass.
  • npm_builder returns a function to use in a prebuild step and has the same interface as the current npm_install
  • get_data_files: handles nested data files for generated static assets - gives back a spec
• We deprecate the existing functions that affect data_files and package_data using deprecation, which prints a warning about when it will be removed (in 1.0), and what to use instead

Build Backend

• Once we have the above as a library, we can provide all of this declaratively as a build-backend in pyproject.toml that extends setuptools.build_meta

[blink1073]

Thanks!