iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

copy editing

This commit is contained in:
Tarek Ziadé 2009-12-08 23:12:59 +00:00
parent a97586edfe
commit 1d6ddef36f
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
pep-0386.txt
View File

@ -21,13 +21,13 @@ Motivation
In Python there are no real restriction yet on how a project should manage its
versions, and how they should be incremented.
Distutile provides a `version` distribution meta-data field but it is freeform and
Distutils provides a `version` distribution meta-data field but it is freeform and
current users, such as PyPI usually consider the latest version pushed as the
`latest` one, regardless of the expected semantics.
Distutils will soon extend its capabilities to allow distributions to express a
dependency on other distributions through the ``Requires-Dist`` metadata field
(see PEP 345 [#pep345]_) and it will optionally allow to use that field to
(see PEP 345 [#pep345]_) and it will optionally allow use of that field to
restrict the dependency to a set of compatible versions. Notice that this field
is replacing ``Requires`` that was expressing dependencies on modules and packages.
@ -37,8 +37,8 @@ compatible versions, so one may write::
Requires-Dist: zope.interface (>3.5.0)
This means that the distribution requires ``zope.interface``, as long as its
version is superior to ``3.5.0``.
This means that the distribution requires ``zope.interface`` with a version
greater than ``3.5.0``.
This also means that Python projects will need to follow the same convention
as the tool that will be used to install them, so they are able to compare
@ -55,10 +55,10 @@ distribution versions compare.
Requisites and current status
=============================
It is not in the scope of this PEP to come with an universal versioning schema,
intented to support many or all existing versioning schemas. There will always
be competing grammars, either mandated by distro or project policies or by
historical reasons and we cannot expect that to change.
It is not in the scope of this PEP to provide a universal versioning schema intended
to support many or all existing versioning schemas. There will always be competing
grammars, either mandated by distro or project policies or by historical
reasons and we cannot expect that to change.
The proposed schema should be able to express the usual versioning semantics,
so it's possible to parse any alternative versioning schema and transform it