[Distutils] Name arbitration on PyPI - how about administrative abandonment/replacement meta-data

Ronny Pfannschmidt opensource at ronnypfannschmidt.de
Tue Apr 19 12:45:45 EDT 2016


Instead of overtaking,
how about clearly marking packages as abandoned/maintained clearly
pointing out the mark was imposed by community action
 and listing potential/primary replacements

this would have the possibility of also supporting normal abandonment
when people voluntary stop maintenance and cannot find a successor

its important that community imposed abandonment is not simply removable
by doing a minor "noop"-release,
after all if abandonment had to be applied by proof of 3rd party, there
is need of proof of continued maintenance

pip could warn on installation/update

-- Ronny

Am 18.04.2016 um 23:31 schrieb Ian Cordasco:
> On Mon, Apr 18, 2016 at 4:16 PM, Chris Barker <chris.barker at noaa.gov> wrote:
>> You've made a strong case, and this is probably not where PyPi should go --
>> but it would hardly be a disaster:
>>
>>> The idea of expiring out names has been brought up recently to resolve an
>>> issue of two packages, one popular and large; another someone's weekend
>>> project.
>>
>> The issue here is not that it's a weekend project, but that it may be an
>> abandoned project. I don't think anyone suggest that we should have a
>> popularity or quality test to see who gets to trump whom with name
>> allocation -- I sure didn't.
>>
>> Which is quite relevant to below:
>>
>>> 1.  PyYAML is a package that would be de-registered in such a scheme.  It
>>> is a highly used, extremely popular, package that unserializes text into
>>> arbitrary python objects.  It is a trusted package... and one that hasn't
>>> been active in ages.
>>
>> and you don't think ANYONE would be willing to take on the miniscule amount
>> of work to maintain the name? Plus there would be any number of other
>> schemes for determining whether a project name is abandoned.
> I have in fact offered but the author refuses to accept help from
> anyone. They're also the author of the C library (libyaml) and they do
> not maintain that either. It's actually quite frustrating as someone
> who wants to fix some of the numerous bugs in the library + improve it
> and add support for YAML 1.2 which is years old at this point.
>
>>> 2. the package tooling already assumes that names will always point to
>>> one, and only one package.  ever.  until the heat death of the universe or
>>> the death of the language whichever is first.
>>
>> IIUC, the current scheme allows for a name to be "taken over" by a new
>> package if the original author so desires -- i.e. if the current owner of
>> the mypy name was happy to relinquish it, then "pip install mypy" would get
>> users something totally different 6 months from now. So no -- we don't
>> currently guarantee anything about future use of names. Other that that the
>> original author can do whatever they want with it.
>>
>>> 3. Who in the PSF really wants that bureaucratic nightmare of arbitrating
>>> cases when this inevitably messes up, be this system manual or automatic?
>>
>> I think bureaucratic nightmare is pretty hyperbolic, but yes, there would be
>> some overhead, for sure. And given that no one has the time and motivation
>> to even maintain PyPi at this point -- this will probably kill the idea
>> altogether.
>>
>>
>>> To the specifics of the mypy-lang package that brought this up... It's
>>> like naming your company "Yahoo", and getting upset that yahoo.com is
>>> getting a bump in traffic because of your popularity.
>>
>> Again - this is not about minor weekend projects not be "important". It's
>> about potential abandonware -- with domain registration, "Yahoo" can offer
>> to buy the domain from the current holder, or, if the current owner has
>> abandoned it, it will go into the public pool again when they stop paying to
>> maintain the registration.
>>
>> -CHB
>>
>>
>> --
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R            (206) 526-6959   voice
>> 7600 Sand Point Way NE   (206) 526-6329   fax
>> Seattle, WA  98115       (206) 526-6317   main reception
>>
>> Chris.Barker at noaa.gov
>>
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig



More information about the Distutils-SIG mailing list