Re: [Distutils] The mypy package

2016-04-18 Thread David Wilson
On Mon, Apr 18, 2016 at 08:18:37AM -0700, Chris Barker - NOAA Federal wrote: > We really should have SOME way to determine if a PyPi name has been > abandoned. Or even be proactive--PyPi names must be maintained in SOME > way, perhaps: +1 > Respond to some sort of "do you still want this"

Re: [Distutils] The mypy package

2016-04-18 Thread David Wilson
On Mon, Apr 18, 2016 at 09:34:09AM -0700, Chris Barker wrote: > Namespaces seem like a great idea, then these problems disappear > entirely, > huh? as far as I can tell, namespaces greatly expand the pool of available > names, but other than that, we've got the same problem. They seem

Re: [Distutils] The mypy package

2016-04-18 Thread Chris Barker
On Mon, Apr 18, 2016 at 8:21 AM, Jim Fulton wrote: > I suggest measuring activity by downloads, not releases. Sometimes > maintained packages are boring enough not to need releases, while many > projects depend on them. > so this is the tricky bit -- in the mypy case, it's

Re: [Distutils] The mypy package

2016-04-18 Thread Chris Barker
On Mon, Apr 18, 2016 at 8:48 AM, David Wilson wrote: > Namespaces seem like a great idea, then these problems disappear > entirely, huh? as far as I can tell, namespaces greatly expand the pool of available names, but other than that, we've got the same problem.

[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

Re: [Distutils] The mypy package

2016-04-18 Thread Alexander Walters
On 4/18/2016 11:18, Chris Barker - NOAA Federal wrote: Domain names are a different system -- you need to maintain your registration. Except, that wasn't my point. My point was I ignore people asking to buy my domain from me because the registered name is part of my identity. PyPi names, on

Re: [Distutils] The mypy package

2016-04-18 Thread Alexander Walters
Greatly expanding the pool of names solves the problem. On 4/18/2016 12:34, Chris Barker wrote: On Mon, Apr 18, 2016 at 8:48 AM, David Wilson > wrote: Namespaces seem like a great idea, then these problems disappear

Re: [Distutils] The mypy package

2016-04-18 Thread Chris Barker
On Mon, Apr 18, 2016 at 9:41 AM, David Wilson wrote: > > huh? as far as I can tell, namespaces greatly expand the pool of > available > > names, but other than that, we've got the same problem. > > They seem to have worked well enough from the 1980s through to the

Re: [Distutils] The mypy package

2016-04-18 Thread Chris Barker
On Mon, Apr 18, 2016 at 9:37 AM, Alexander Walters wrote: > Greatly expanding the pool of names solves the problem. > some of it, maybe, but not the problem at hand -- mypy has already put itself up as "mypy-lang", an namespace would be pretty much the same thing. if

Re: [Distutils] The mypy package

2016-04-18 Thread Chris Barker
On Mon, Apr 18, 2016 at 9:30 AM, Alexander Walters wrote: > We absolutely do not. Names are first come, first serve, in perpetuity. I'm suggesting that the "in perpetuity" bit is NOT a good way to go -- packages are abandoned, and the longer this goes on, the more

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

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 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

Re: [Distutils] The mypy package

2016-04-18 Thread Ionel Cristian Mărieș
On Mon, Apr 18, 2016 at 11:47 PM, Chris Barker wrote: > > I'm suggesting that the "in perpetuity" bit is NOT a good way to go -- > packages are abandoned, and the longer this goes on, the more issues will > arise. > > ​Problem is cat's out of the bag here. There are three

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] The mypy package

2016-04-18 Thread Glyph
> On Apr 18, 2016, at 3:17 PM, Alex Grönholm wrote: > > This name is unfortunately a bit awkward in the author's native language -- > it is the colloquial word for "babe" or "broad" :) OK, I didn't see that one coming :-). "stapy", then? "static type annotation

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] The mypy package

2016-04-18 Thread Alexander Walters
I described at a high level what mypy-lang does to my wife, and the brief history of this issue. Her blerted out solution was to "just change mypy-lang to annopy" (for annotated python). I am required by marital obligation to bring that forward. On 4/18/2016 18:21, Glyph wrote: On Apr

Re: [Distutils] pip install -e foo (without Repo URL)

2016-04-18 Thread Thomas Güttler
Am 15.04.2016 um 14:12 schrieb Alex Grönholm: To my knowledge, metadata 2.0 does not have any reliable means to specify a repository URL. So how do you propose to retrieve this information? How to retrieve the information? I don't know. Where is the best place to store meta information for

Re: [Distutils] The mypy package

2016-04-18 Thread Chris Barker - NOAA Federal
> Though I do wonder how effective that would be in this case. For all we > know, in the case of mypy, the maintainer is simply ignoring someone else who > is trying to take the name they registered. (I get emails all the time for > people trying to get me to sign over my domain names;

Re: [Distutils] The mypy package

2016-04-18 Thread Jim Fulton
I suggest measuring activity by downloads, not releases. Sometimes maintained packages are boring enough not to need releases, while many projects depend on them. Jim On Mon, Apr 18, 2016 at 11:18 AM, Chris Barker - NOAA Federal wrote: >> Though I do wonder how effective

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] The mypy package

2016-04-18 Thread Glyph
> On Apr 18, 2016, at 2:00 PM, Chris Barker wrote: > > On Mon, Apr 18, 2016 at 9:37 AM, Alexander Walters > wrote: > Greatly expanding the pool of names solves the problem. > > some of it, maybe, but not the

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

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 (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

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 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 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] The mypy package

2016-04-18 Thread Wayne Werner
On Mon, Apr 18, 2016 at 10:21 AM, Jim Fulton wrote: > I suggest measuring activity by downloads, not releases. Sometimes > maintained packages are boring enough not to need releases, while many > projects depend on them. > I don't know about on pypi, but I know in general