[Catalog-sig] PEP 314: Updating the package metadata format
A.M. Kuchling
amk@amk.ca
Sat, 12 Apr 2003 09:11:24 -0400
At PyCon there was a Distribution BoF that I found very helpful, and
that convinced me that taking care of dependencies is feasible. See
http://www.amk.ca/diary/2003/03/28.html#2003-03-28-4 for my full
account.
One step that isn't listed in the TODO list in that entry is updating
the metadata format specified in PEP 241 to include requirements and
dependencies. The updated specification has been allocated PEP 314.
Rather than post the whole document, making it difficult to see the
changes, a diff between the old and new version is included below.
Please comment on the changes.
--amk (www.amk.ca)
HIPPOLYTA: I never heard so musical a discord, such sweet thunder.
-- _A Midsummer Night's Dream_, IV, i
Index: pep-0314.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0314.txt,v
retrieving revision 1.1
retrieving revision 1.3
diff -u -u -r1.1 -r1.3
--- pep-0314.txt 12 Apr 2003 19:45:01 -0000 1.1
+++ pep-0314.txt 12 Apr 2003 21:16:50 -0000 1.3
@@ -13,6 +13,8 @@
packages. It includes specifics of the field names, and their
semantics and usage.
+ This document specifies version 1.1 of the metadata format.
+ Version 1.0 is specified in PEP 241.
Including Metadata in Packages
@@ -48,12 +50,12 @@
Metadata-Version
- Version of the file format; currently "1.0" is the only
- legal value here.
+ Version of the file format; currently "1.0" and "1.1" are the
+ only legal values here.
Example:
- Metadata-Version: 1.0
+ Metadata-Version: 1.1
Name
@@ -211,16 +213,99 @@
License: MIT
+ Requires (multiple use)
+
+ Each entry contains a string describing some other component or
+ module required by this package.
+
+ The format of a requirement string is simple: an arbitrary
+ sequence of characters, optionally followed by a version
+ declaration within parentheses. Leading and trailing whitespace
+ are ignored, and whitespace within the string is normalized to a
+ single space.
+
+ A version declaration is a series of conditional operators and
+ version numbers, separated by commas. Conditional operators
+ must be one of "<", ">", "<=", ">=", "=", and "!=". Version
+ numbers must be in the format accepted by the
+ distutils.version.StrictVersion class: two or three
+ dot-separated numeric components, with an optional "pre-release"
+ tag on the end consisting of the letter 'a' or 'b' followed by a
+ number. Example version numbers are "1.0", "2.3a2", "1.3.99",
+
+ XXX Do we really need = and !=?
+
+ XXX Should it be == or =?
+
+ XXX Should we support LooseVersion instead of StrictVersion?
+ LooseVersions aren't comparable...
+
+ Any number of conditional operators can be specified, e.g.
+ ">1.0, !=1.3.4, <2.0".
+
+ All of the following are possible requirement strings: "rfc822",
+ "", "zlib (>=1.1.4)", "XML parser".
+
+ There's no canonical list of what strings should be used; the
+ Python community is left to choose its own standards.
+
+ Example:
+
+ Requires: re
+ Requires: sys
+ Requires: zlib
+ Requires: pyexpat (>1.0)
+ Requires: DB-API 2.0 module
+
+ Provides (multiple use)
+
+ Each entry contains a string describing a component or
+ module that will be provided by this package once it is
+ installed. These strings should match the ones used in
+ Requirements fields. Version declarations cannot be supplied;
+ instead the package's version number will be used.
+
+ Example:
+
+ Provides: xml
+ Provides: xml.utils
+ Provides: xml.utils.iso8601
+ Provides: xml.dom
+
+ Obsoletes (multiple use)
+
+ Each entry contains a string describing a component or module
+ that this package renders obsolete, meaning that the two packages
+ should not be installed at the same time. Version declarations
+ cannot be supplied. (XXX Or are they needed for Obsoletes?)
+
+ The most common use of this field will be in case a package name
+ changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0.
+ When you install Torqued Python, the Gorgon package should be
+ removed.
+
+ Example:
+
+ Obsoletes: Gorgon
+
+ Conflicts (multiple use)
+
+ Each entry contains a string describing a component or module
+ that conflicts with this package, meaning that the two packages
+ should not be installed at the same time. Version declarations
+ cannot be supplied.
+
+ Conflict resolution probably isn't very important for Python
+ programs, because few extensions will cause problems for other
+ extensions, unless they're using the same package name. This
+ field name is being defined here for future use.
+
+ Conflicts: Gorgon
+
Acknowledgements
- Many changes and rewrites to this document were suggested by the
- readers of the Distutils SIG. In particular, Sean Reifschneider
- often contributed actual text for inclusion in this PEP.
-
- The list of licenses was compiled using the SourceForge license
- list and the CTAN license list compiled by Graham Williams; Carey
- Evans also offered several useful suggestions on this list.
+ None yet.
Copyright