[Python-Dev] Marking packaging-related PEPs as Finished after fixing some bugs in them

[Éric Araujo]

  Hello,

  The three packaging-related PEPs that were written by the distutils
SIG and approved two years ago are still marked as Accepted, not Finished:

 SA  345  Metadata for Python Software Packages 1.2               Jones
 SA  376  Database of Installed Python Distributions              Ziadé
 SA  386  Changing the version comparison module in Distutils     Ziadé

  They’re all implemented in packaging/distutils2.  Sadly, all of them
have rather serious issues, so I wanted to ask what the process should
be to solve the problems and mark the PEPs final.

  In PEP 345, legal values for project names are not defined, so for
example “Foo (>=0.5)” could legally be a project named Foo without
version predicate, or a project named “Foo (>=0.5)”.  I don’t have a
solution to propose, as I did not run a poll or check existing projects.
  Second, the Provides-Dist allows values like “Name (<= version)”,
which does not make sense: it should allow only unversioned names and
names with one version (without operators).
  Finally, some of the new metadata fields are also misnamed, namely the
ones ending in -Dist like Requires-Dist, whose value is a release (i.e.
a name + optional version specifier), not a distribution (i.e. a
specific archive or installer for a release), and therefore should be
Requires-Release or something prettier.  (Remember that it cannot be
just Requires, which is taken by PEP 314, contains module names instead
of project names, and is not used by anyone TTBOMK.)

  packaging.database, which implements PEP 376, has a few known bugs; I
don’t know if that should prevent the PEP from being marked Finished.
It could be that finishing the implementation shows issues in the PEP,
like for the other two.

  In PEP 386, the rule that versions using an 'rc' marker should sort
after 'c' is buggy: I don’t think anyone will disagree that 1.0rc1 ==
1.0c1 and 1.0rc1 < 1.0c2.  The 'rc' marker was added by Tarek shortly
before the PEP was accepted (see
http://mail.python.org/pipermail/python-dev/2010-January/097041.html),
and was not discussed.  My preferred solution would be to accept 'rc'
when parsing but then always use 'c' internally and in all output (file
names, METADATA file, etc.).  If it is judged important that projects be
able to use 'rc' and see it in output, then I’ll have to add special
cases in __eq__ and __hash__ methods, which is feasible if inelegant.

  (Issues found by Josip Djolonga, Alexis Métaireau and I.)

  Cheers