PEP 639 compliance

[DimitriPapadopoulos]

See https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license-and-license-files.

[RonnyPfannschmidt]

windows errors are unrelated and fixed in another pr

[RonnyPfannschmidt]

this implicitly makes the project python 3.9 plus - so it will have to wait until after the 8.4 release as i want to ensure bugfixes for build issues with python3.8 and 3.9 deliver to down-streams/enterprise distro users

[DimitriPapadopoulos]

Additionally, part of the ecosystem (pip-licenses) doesn't support PEP 639 yet.

[DimitriPapadopoulos]

I believe setuptools does not need an explicit license-files key according to Controlling files in the distribution:

• All files specified by the license-files configuration parameter in pyproject.toml and/or equivalent in setup.cfg/setup.py; note that if you don’t explicitly set this parameter, setuptools will include any files that match the following glob patterns: LICEN[CS]E*, COPYING*, NOTICE*, AUTHORS**;

@RonnyPfannschmidt Do you prefer implicit or explicit?

[RonnyPfannschmidt]

implicit please

[DimitriPapadopoulos]

Perhaps implicit is not a good idea after all. From Appendix: Rejected Ideas:

Use a default value for license-files if not specified

A previous draft of the PEP proposed a default value for detecting license files in case the users have not declared any and not marked the key as dynamic. That value was defined as an array of globs:

["LICEN[CS]E*", "COPYING*", "NOTICE*", "AUTHORS*"]

However, this would create an exception among the existing metadata, as no other key has got implicit defaults defined. Implicit values in pyproject.toml keys are delegated to the dynamic field, which is specified as being calculated. Also, the values were chosen arbitrarily, without a strong justification why they should pose a standard.

The implicit default values look like a leftover from an experimental feature that eventually got rejected.

[RonnyPfannschmidt]

thanks for preparing this - the failing tests are from python versions to remove

[RonnyPfannschmidt]

afte the next release i'll take this into the branch for the next version

[RonnyPfannschmidt]

i merged this in my prep branch, please no longer force push as that would disconnect history