Remove some 'XXX' comments.
Use '==' in version declarations Add some PEP headers.
This commit is contained in:
parent
c0fdeb751f
commit
2e7a3619ef
25
pep-0314.txt
25
pep-0314.txt
|
@ -1,11 +1,15 @@
|
|||
PEP: 314
|
||||
Title: Metadata for Python Software Packages v1.1
|
||||
Version: $Revision$
|
||||
Last-Modified: $Date$
|
||||
Author: A.M. Kuchling <amk@amk.ca>
|
||||
Type: Standards Track
|
||||
Created: 12-Apr-2003
|
||||
Status: Draft
|
||||
Type: Standards Track
|
||||
Content-type: text/plain
|
||||
Created: 12-Apr-2003
|
||||
Python-Version: 2.3
|
||||
Post-History:
|
||||
Replaces: 243
|
||||
|
||||
Introduction
|
||||
|
||||
|
@ -226,25 +230,18 @@ Fields
|
|||
|
||||
A version declaration is a series of conditional operators and
|
||||
version numbers, separated by commas. Conditional operators
|
||||
must be one of "<", ">", "<=", ">=", "=", and "!=". Version
|
||||
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".
|
||||
the string ">1.0, !=1.3.4, <2.0" is a legal version declaration.
|
||||
|
||||
All of the following are possible requirement strings: "rfc822",
|
||||
"", "zlib (>=1.1.4)", "XML parser".
|
||||
"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.
|
||||
|
@ -297,8 +294,8 @@ Fields
|
|||
|
||||
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.
|
||||
extensions, unless they happen to be using the same package
|
||||
name. This field name is being defined here for future use.
|
||||
|
||||
Conflicts: Gorgon
|
||||
|
||||
|
|
Loading…
Reference in New Issue