Differences between revisions 6 and 7
Revision 6 as of 2009-04-04 17:11:06
Size: 4485
Editor: ip72-219-215-123
Comment:
Revision 7 as of 2009-04-21 22:27:24
Size: 4479
Editor: eth595
Comment: copy edit
Deletions are marked like this. Additions are marked like this.
Line 13: Line 13:
 * deprecate Requires/Provides/OBsolete.  * deprecate Requires/Provides/Obsolete.
Line 15: Line 15:
 * deprecate the MANIFEST.in template system in favor of a more powerfull pakage_data  * deprecate the MANIFEST.in template system in favor of a more powerful package_data
Line 17: Line 17:
 * see if we want to have a new "python version" metadata  (it's a trove classifier right now)  * see if we want to have a new "python version" metadata (it's a trove classifier right now)
Line 30: Line 30:
 * 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  * 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.
Line 32: Line 32:
 * 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  * The Python version dependency is already in PEP 345. (Incidentally, I was under the mis-impression that PEP 345 introduced Requires/Provides, but they were introduced in PEP 314.)
Line 34: Line 34:
 * 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.  * 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 it is now. I'm not opposed to someone making a separate distutils release, but I don't think the benefit is worth the effort.
Line 36: Line 36:
 * 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 do think it would be very valuable to get install_requires data into PyPI. This raises the question of what to do about dependencies of dependencies on different Python versions.
Line 48: Line 48:
to just appropriate the 'Requires:', 'Obsoletes:', and 'Provides:' headers to just appropriate the 'Requires:', 'Obsoletes:', and 'Provides:' fields

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 powerful package_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.
  • The Python version dependency is already in PEP 345. (Incidentally, I was under the mis-impression that PEP 345 introduced Requires/Provides, but they were introduced in PEP 314.)
  • 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 it is 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 valuable to get install_requires data into PyPI. This raises 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

Tres Seaver's comments

After working with Matthias Klose, I honestly cannot see any reason not to just appropriate the 'Requires:', 'Obsoletes:', and 'Provides:' fields already implemented in PEP 314. There are no other *real* semantics for those fields besides the ones we want.

Note that we need to keep the 'PKG-INFO' fieldnames / semantics distinct from the values passed to 'setup()': in particular, the 'install_requires' argument could easily map onto the 'Requires:' field.

My proposal:

  • Get the list of existing packages on PyPI which spell 'Requires:', 'Provides:', and 'Obsoletes:', and look at the values which are present. See Martin v. Loewis's stats here:
  • Update the not-yet-released PEP 345, documenting the desired semantics for the 'Requires:', 'Provides:', and 'Obsoletes:' fields. In particular, note that the names in these fields are preferentially distutils projects, rather than package / module names. Document the semantics of the version strings according to the consensus proposal

    from PyCon (the 'verlib.py' version).

  • Update distutils, adding an API for querying values stored in PKG-INFO fields (avoiding running 'setup.py').
  • Update setuptools such that its 'install_requires' arguments get passed through to the 'distutils.core.Distribution' constructor as 'requires'.
  • Update setuptools to do "soft" requirements on names found in PKG-INFO's 'Requires:': if no distribution matches the project name, then fall back to assuming that it refers to a package / module.

Distutils/Metadata (last edited 2009-04-22 09:27:40 by 115)

Unable to edit the page? See the FrontPage for instructions.