Comparing changes

This eventually will allow reading project metadata directly from `pyproject.toml`

In order to minimise dependencies, `validate-pyproject` has the ability to "dump" only the code necessary to run the validations to a given directory. This special strategy is used instead of the default `pip install -t`. The idea of using JSONSchema for validation was suggested in pypa#2671, and the rationale for that approach is further discussed in https://github.com/abravalheri/validate-pyproject/blob/main/docs/faq.rst Using a library such as `validate-pyproject` has the advantage of incentive sing reuse and collaboration with other projects. Currently `validate-pyproject` ships a JSONSchema for the proposed use of `pyproject.toml` as means of configuration for setuptools. In the future, if there is interest, setuptools could also ship its own schema and just use the shared infrastructure of `validate-pyproject` (by advertising the schemas via entry-points).

This is the first step towards making setuptools understand `pyproject.toml` as a configuration file. The implementation deliberately allows splitting the act of loading the configuration from a file in 2 stages: the reading of the file itself and the expansion of directives (and other derived information).

The user might specify dynamic `entry-points` via a `file:` directive (a similar feature for `setup.cfg` is documented in [declarative config]). The changes introduced here add the ability to expand them when reading the configuration from `pyproject.toml`. [declarative config]: https://setuptools.pypa.io/en/latest/userguide/declarative_config.html

There is frequent an opinion in the community that `include_package_data=True` is a better default (and a quality of life improvement). Since we are migrating to a new configuration file, this change can be implemented in a backward compatible way (to avoid breaking existing packages): - Config from `setup.cfg` defaults to `include_package_data=False` - Config from `pyproject.toml` defaults to `include_package_data=True` This also takes advantage that `ini2toml` (the provided library for automatic conversion between `setup.cfg` and `pyproject.toml`) will backfill `include_package_data=False` when the field is missing.

Since the Distrubition and DistributionMetadata classes are modeled after (an old version of) core metadata, it is necessary to add a translation layer between them and the configuration read from pyproject.toml

The apply_configuration is implemented in a way that it is consistent for both pyproject.toml and setup.cfg

(Merge branch 'dist-config-from-pyproject' into support-pyproject) This change targets adding a standardised project configuration format as initially proposed by PEP 621 (with the possibility of modification/evolution according to follow-up PEPs). For the configuration fields not covered by the standards, the approach proposed in https://ini2toml.readthedocs.io/en/latest/setuptools_pep621.html is adopted. The external libraries `tomli` and `validate-pyproject` are vendorised to support this operation.

Since now setuptools supports 2 types of files for configuration (`setup.cfg` and `pyproject.toml`), it is very trick to provide a single `read_configuration` function that will provide compatible outputs for both formats. Instead the `config.{setupcfg,pyprojecttoml}` modules have their own `read_configuration` functions that differ between themselves in terms of arguments and format of the return value. Therefore the users should be importing directly the specific submodule and calling the read function from there. The `config.setupcfg` submodule is advertised as "provisional" in the deprecation note because the main proposal debated in the setuptools issue tracker reached some level of consensus around deprecating `setup.cfg` files.

(Merge branch 'integration' into support-pyproject) This change builds on top of the recently added ability to parse and apply configurations from TOML files to distribution objects by tapping into the existing mechanism for handling configuration and making these TOML files to be read by default. A series of deprecation warnings and tests is also added.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comparing changes

Open a pull request

Commits on Jan 24, 2022

This comparison is taking too long to generate.

Uh oh!