On Tue, Nov 20, 2012 at 4:07 PM, Glenn Linderman <v+pyt...@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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
