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
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Tshepang Lekhonkhobe]

On Mon, Feb 27, 2012 at 12:40, Éric Araujo <[hidden email]> wrote:

>  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.

I also didn't like the fact that 'rc' > 'c'. The change you are
proposing will also make the code change far simpler.

Note that the code (the one in the main VCS), sort of assumed that
'rc'=='c', but is missing the assignment, and therefore broken.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Antoine Pitrou]

On Mon, 27 Feb 2012 11:40:08 +0100
Éric Araujo <[hidden email]> wrote:

>
>   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.

'rc' makes sense to most people while 'c' is generally unheard of.

Regards

Antoine.


>
>   (Issues found by Josip Djolonga, Alexis Métaireau and I.)
>
>   Cheers
> _______________________________________________
> Python-Dev mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Barry Warsaw]

On Feb 27, 2012, at 11:40 AM, Éric Araujo wrote:

>  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.

From a process point of view, I'd say you should fix the PEP issues you know
about, and publish new versions, updating the Post-History field.  These PEPs
were written before the BDFOP/Czar policy came about, so why not see if you
can find someone acceptable to Guido (or maybe suggested by him) to pronounce
on the PEPs.  Then, if the BDFOP agrees you can mark them Final, since I think
they almost are, effectively.

Marking them Final doesn't mean they can't be updated if you find some issues
with them later.  You and the BDFOP might decide to defer Final acceptance
until the bugs in the implementations are fixed though.

Cheers,
-Barry
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Terry Reedy]

On 2/27/2012 6:50 AM, Antoine Pitrou wrote:

> 'rc' makes sense to most people while 'c' is generally unheard of.

'rc' following 'a' and 'b' only makes sense to people who are used to it
and know what it means. 'c' for 'candidate' makes more sense to me both
a decade ago and now. 'rc' is inconsistent. Why not 'ra' for 'release
alpha' or 'ar' for 'alpha release'? In other words, all releases are
releases, so why not be consistent and either always or never include
'r'? (Never would be better since always is redundant.)

I suspect many non-developer users find 'rc' as surprising as I did.

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Steven D'Aprano-8]

Terry Reedy wrote:

> On 2/27/2012 6:50 AM, Antoine Pitrou wrote:
>
>> 'rc' makes sense to most people while 'c' is generally unheard of.
>
> 'rc' following 'a' and 'b' only makes sense to people who are used to it
> and know what it means. 'c' for 'candidate' makes more sense to me both
> a decade ago and now. 'rc' is inconsistent. Why not 'ra' for 'release
> alpha' or 'ar' for 'alpha release'? In other words, all releases are
> releases, so why not be consistent and either always or never include
> 'r'? (Never would be better since always is redundant.)
>
> I suspect many non-developer users find 'rc' as surprising as I did.

Yes, but you should only find it surprising *once*, the first time you learn
about the standard release schedule:

pre-alpha
alpha
beta
release candidate
production release

http://en.wikipedia.org/wiki/Software_release_life_cycle

Not all releases are equivalent. In English, we can not only verbify nouns,
but we can also nounify verbs. So, yes, any software which is released is *a*
release; but only the last, production-ready release is *the* release. The
others are pre-release releases.

Ain't English grand?

If if you prefer a more wordy but slightly less confusing way of saying it,
they are pre-release versions which have been released.

This reply of mine on the python-list list may also be relevant:

http://mail.python.org/pipermail/python-list/2012-February/1288569.html


--
Steven
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com