[Python-Dev] Accept just PEP-0426
pje at telecommunity.com
Tue Nov 20 22:48:51 CET 2012
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
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...
More information about the Python-Dev