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

2016-04-20 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/20/2016 04:36 PM, Ronny Pfannschmidt wrote: > its not given lightly, and it shouldn't be easy to weasel out of it. > Actually a noop release is a good indicator that the mark is > well-deserved and should be keept. Making an effort to remove a

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

2016-04-20 Thread Ronny Pfannschmidt
Am 20.04.2016 um 00:38 schrieb Chris Barker: > On Tue, Apr 19, 2016 at 9:45 AM, Ronny Pfannschmidt > > wrote: > > Instead of overtaking, > how about clearly marking packages as abandoned/maintained clearly >

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

2016-04-19 Thread Chris Barker
On Tue, Apr 19, 2016 at 9:45 AM, Ronny Pfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > Instead of overtaking, > how about clearly marking packages as abandoned/maintained clearly > pointing out the mark was imposed by community action > I think that would be a good idea -- and maybe

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

2016-04-19 Thread Ronny Pfannschmidt
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

Re: [Distutils] Name arbitration on PyPI

2016-04-18 Thread Alexander Walters
Here here. As to the concept of a name being community owned vs. registrant owned - I am very opposed to changing the rules mid-stream. If community ownership is to be a thing (and I do not want it to be a thing at all, but if it is), it should be *from this point forward* the names are

Re: [Distutils] Name arbitration on PyPI

2016-04-18 Thread Alex Grönholm
Here: https://pypi.python.org/pypi/PIL It was downloadable until external downloads were disallowed. 19.04.2016, 01:49, Chris Barker - NOAA Federal kirjoitti: Another high profile example of such a project: PIL. Was PIL ever on PyPi? Anyway, yup, the solution there was to fork give it s

Re: [Distutils] Name arbitration on PyPI

2016-04-18 Thread Chris Barker - NOAA Federal
Another high profile example of such a project: PIL. Was PIL ever on PyPi? Anyway, yup, the solution there was to fork give it s new name -- Pillow was born. CHB 19.04.2016, 00:56, Chris Barker kirjoitti: On Mon, Apr 18, 2016 at 2:31 PM, Ian Cordasco wrote: > >>

Re: [Distutils] Name arbitration on PyPI (was: The mypy package)

2016-04-18 Thread Glyph
> On Apr 18, 2016, at 3:21 PM, Donald Stufft wrote: > >> >> On Apr 18, 2016, at 6:14 PM, Glyph > > wrote: >> >> >>> On Apr 18, 2016, at 2:31 PM, Ian Cordasco >>

Re: [Distutils] Name arbitration on PyPI (was: The mypy package)

2016-04-18 Thread Donald Stufft
> On Apr 18, 2016, at 6:14 PM, Glyph wrote: > > >> On Apr 18, 2016, at 2:31 PM, Ian Cordasco > > wrote: >> >> I have in fact offered but the author refuses to accept help from >> anyone. They're also the

Re: [Distutils] Name arbitration on PyPI (was: The mypy package)

2016-04-18 Thread Glyph
> On Apr 18, 2016, at 3:11 PM, Donald Stufft wrote: > > If we mandated semver (or something like it) we could make it so that > transferring a name *forced* a major version bump and the new author would be > unable to release anything using a smaller major version number,

Re: [Distutils] Name arbitration on PyPI (was: The mypy package)

2016-04-18 Thread Glyph
> On Apr 18, 2016, at 2:31 PM, Ian Cordasco wrote: > > 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 >

Re: [Distutils] Name arbitration on PyPI (was: The mypy package)

2016-04-18 Thread Donald Stufft
> On Apr 18, 2016, at 5:16 PM, Chris Barker wrote: > > 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

Re: [Distutils] Name arbitration on PyPI

2016-04-18 Thread Alex Grönholm
Another high profile example of such a project: PIL. 19.04.2016, 00:56, Chris Barker kirjoitti: On Mon, Apr 18, 2016 at 2:31 PM, Ian Cordasco > wrote: >> 1. PyYAML is a package that would be de-registered in such a scheme.

Re: [Distutils] Name arbitration on PyPI (was: The mypy package)

2016-04-18 Thread Chris Barker
On Mon, Apr 18, 2016 at 2:31 PM, Ian Cordasco wrote: > >> 1. PyYAML is a package that would be de-registered in such a scheme. > It > > > and you don't think ANYONE would be willing to take on the miniscule > amount > > of work to maintain the name? Plus there

Re: [Distutils] Name arbitration on PyPI (was: The mypy package)

2016-04-18 Thread Ian Cordasco
On Mon, Apr 18, 2016 at 4:16 PM, Chris Barker 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

Re: [Distutils] Name arbitration on PyPI (was: The mypy package)

2016-04-18 Thread Chris Barker
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

[Distutils] Name arbitration on PyPI (was: The mypy package)

2016-04-18 Thread Alexander Walters
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 general idea being that a project maintainer should be forced to renew their contact information, or face the possibility of the PyPI