This page describes the work done in order to change the Distutils Metadata.
PEP References :
PEP 241 Metadata 1.0 for Python Software Packages
PEP 314 Metadata 1.1 for Python Software Packages
PEP 345 Draft Metadata 1.2 for Python Software Packages
We are working on a new version for PEP 345. Jim started a branch (jim-update-345)
what has been said:
- deprecate Requires/Provides/OBsolete.
- add install_requires
- deprecate the MANIFEST.in template system in favor of a more powerfull pakage_data
- list all the arguments that are passed to vairous commands through setup.py that should land into the new metadata description
- see if we want to have a new "python version" metadata (it's a trove classifier right now)
Jim Fulton's comments
Having looked at this and spoken to folks over the last few days I have a numbner of observations:
* It could be argued that Requires/Provides and install_requires are complementary. At worst, they talk about different things. It is probably still best to deprecate requires and provides as they are likely to be confusing.
- (Note that I think it would be valuable to have some way of saying that a package provides a required feature that can be provided by multiple packages, and that could be required by other packages. This should probably be out of scope of the current effort.)
* I think that install_requires is the only thing that needs to be added. setuptools provides a number of additional features that people might find useful, but they can still use setuptools to provide those features.
* I don't think thet deprecating the existing MANIFEST.in template system needs to be in scope of this effort. I think we should take small incremental steps.1
* The python version dependency is already in PEP 345. (Incidentally, I was under the missinpression that PEP 345 introduced Requires/Provides, but they were introduced in PEP 314.)1
* To make progress, I don't think it is necessary to release distutils externally. I think it would be enough to get install_requires into Python 2.7 and, if possible 3.1. Since it is compatible with setuptools, people who want it in earlier Python versions can use setuptools as they are now. I'm not opposed to someone making a separate distutils release, but I don't think the benefit is worth the effort.
* I do think it would be very valueable to get install_requires data into PyPI. This begs the question of what to do about dependencies of dependencies on different Python versions.
* I think we need a way to handle meta-data extensions. Two use cases:
- extra down-stream meta data
- entry points