[Python-Dev] Accept just PEP-0426

[PJ Eby]

On Tue, Nov 20, 2012 at 4:07 PM, Glenn Linderman <v+python at g.nevcal.com>wrote:

>  On 11/20/2012 12:46 PM, PJ Eby wrote:
>
>  I personally don't think that forks claiming to "provide" something is
> really a good thing to encourage; ISTM that saying a package *conflicts*
> with another is more accurate, e.g. distribute Conflicts-Dist setuptools.
> I also think distributions should say they are obsoleted, rather than
> allowing other distributions to obsolete them.
>
>  Obsolete distributions won't say they are obsoleted, unless they receive
> further maintenance. However, if the distribution is obsolete because the
> maintainer has lost interest, they won't receive further maintenance.
>

(We've been over this before, the last time this discussion came up on the
Distutils-SIG for a previous Metadata PEP a year or two back, but here
goes....)

Obsoleting a package is for handling renames and support transitions.  For
example, if it actually did anything to do so, I'd mark RuleDispatch as
obsoleted-by PEAK, the Pylons folks might mark some version of that as
obsoleted-by Pyramid, etc.  To put it another way, marking a package
obsolete is part of deprecation and replacement, not an unsubstantiated
third-party claim about the maintenance status of an unrelated project.

If a package is *actually* dead, there's no real point to declaring that
something else obsoletes it, and certainly no reason to put it in metadata
form.  Otherwise, we could have Twisted claiming to obsolete GEvent and
vice-versa at the same time.  Which one should an installer believe?  It
makes no sense in a standard where the project's maintainers can say
whatever they want about somebody else's project.  The scope of authority
for automatically-consumed metadata should *only* encompass the project
that provided the metadata.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121120/9b613f22/attachment.html>