[Distutils] Review of latest draft of PEP 426 (Python package etadata v1.3)

Nick Coghlan ncoghlan at gmail.com
Thu Jan 31 07:20:09 CET 2013

On Wed, Jan 30, 2013 at 10:54 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 30 January 2013 12:32, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
>> I'm not sure I understand this point. Shouldn't that default be "pkg_resources",
>> given that all the existing distributions on PyPI will work with that scheme and
>> not have the Version-Scheme present in their metadata?
> I assumed that the idea is that if you upgrade your metadata to 1.3,
> you are expected to switch to the new version scheme unless you
> explicitly state that you're opting out of that part of the standard.

Correct. The desire is still to migrate to a more formal versioning
scheme, hence PEP 386 by default if no Version-Scheme is specified.
However, I don't want "but what if PEP 386 doesn't handle my
pre/post/whatever release naming correctly" to be a potential blocker
for migration the way it is with v1.2 of the metadata spec.

The "Version-Scheme: pkg_resources" escape hatch will hopefully be
enough to decouple the "provide v1.3 metadata" decision from the "use
PEP 386 compatible version numbering" decision and thus lower the
barrier to adoption for the *other* metadata features in the new
versions (like consistent UTF-8 encoding, description-as-payload,
Obsoleted-By, optional components/dependencies and the metadata
extension mechanism, as well as those originally added in v1.2, such
as distribution level dependencies, additional URLs and the
environment marker concept).


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Distutils-SIG mailing list