date:20160418

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 pretty clear that many
of the downloads are mistakes. maybe many of them are real use cases also
-- how to know? there is no way to know!

Yes, it's possible that:

 - someone puts something up n pypi.
 - that someone abandons the project.
 - no one picks up maintenance for the project
 - other people still find it useful --- many years into the future.

This is the one edge-case that is the real trick. Personally, I would argue
that a completely and totally abandoned project would be OK to remove from
pypi (Not any time really fast). If you can't even get anyone to step and
say: "sure -- I'll respond to an email once a year to keep this alive",
then you really have a pretty darn dead project.

The trick is how to make this process work. Maybe an apparently abandoned
project gets a "might-be-abandoned" tag. Then its page geta a prominent --
"We need someone to take this over" message. Maybe even a way to pass a
message off to folks that install it via pypi. If no one steps up for, say,
a year or so, then it gets removed. We could even make that provisional,
for another period of time, so folks trying to download it would get a
message saying:

This package appears to be abandoned -- if you would like adopt it, please
do such and such"

They key point ist hat the barrier to entry for grabbing a name on pypi is
very, very low. maybe the barrier to KEEP that name should be equally low
-- rather than non-existant.

I think the domain name system is a fine parallel -- if you want to keep
your domain name, you need to keep your registration up -- all that takes
is a few bucks a year (and in this case, we wouldn't even ask for a few
bucks) but you need to do SOMETHING -- you can't just abandon it and keep
everyone else from using it forever.

And note that it's possible for someone to put up a useful web site on a
free hosting service, attach it to their domain name, and then abandon it
-- sure, there may be someone out there that finds that site useful years
from now -- but those are the breaks.

-CHB




> Jim
>
> On Mon, Apr 18, 2016 at 11:18 AM, Chris Barker - NOAA Federal
>  wrote:
> >> 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;
> >
> > Domain names are a different system -- you need to maintain your
> registration.
> >
> > PyPi names, on the other hand, are all too easy to setup, and then
> > completely ignore, maybe even forget you used it.
> >
> > 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:
> >
> > Push a change or update at least once a year (or some other interval).
> >
> > Or
> >
> > Respond to some sort of "do you still want this" email. At least once a
> year.
> >
> > If neither of these occurs, then we could have a deprecation period.
> >
> > Details aside, as PyPi continues to grow, we really need a way to
> > clear out the abandoned stuff -- the barrier to entry for creating a
> > new name on PyPi is just too low.
> >
> > This is all too late for MyPy, but it has certainly come up before,
> > and will again, more and more.
> >
> > -CHB
> > ___
> > Distutils-SIG maillist  -  Distutils-SIG@python.org
> > https://mail.python.org/mailman/listinfo/distutils-sig
>
>
>
> --
> Jim Fulton
> http://jimfulton.info
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The mypy package

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.

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

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 name they registered being de-registered and 
made available for another package to use.


Preamble done, let me enumerate why this is just a disaster:

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.  This is prime malware bait.


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.  If I am the one person 
in the world who actually depends on the 'mypy' (not mypy-lang) package, 
you have broken that trust.


3. Who in the PSF really wants that bureaucratic nightmare of 
arbitrating cases when this inevitably messes up, be this system manual 
or automatic?


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. It is unfortunate 
that the mypy-lang developers failed to check pypi for name availability 
before they named their package, but it is by no means a reason to 
invite malicious code into the index, break the trust of the tooling, or 
create a bureaucracy to manage when the first two happen.

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The mypy package


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 the other hand, are all too easy to setup, and then
completely ignore, maybe even forget you used it.

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:

Why?

Push a change or update at least once a year (or some other interval).

What if your code doesn't need an update?


Or

Respond to some sort of "do you still want this" email. At least once a year.

And how many times have you missed an automated email?

If neither of these occurs, then we could have a deprecation period.

Details aside, as PyPi continues to grow, we really need a way to
clear out the abandoned stuff -- the barrier to entry for creating a
new name on PyPi is just too low.
We absolutely do not.  Names are first come, first serve, in 
perpetuity.  Changing this changes the security model of pypi.  If all 
an attacker has to do is wait out an old, but still highly downloaded 
package... why wouldn't they do it?


This is all too late for MyPy, but it has certainly come up before,
and will again, more and more.

-CHB


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The mypy package


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


-CHB




--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov 


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The mypy package

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 3.5bn
> or so Internet users we have today.
>

but people don't get domain names in perpetuity without maintaining them --
not the same thing.

And the problem at hand is that the mypy folks don't to use a different
name, and it would better serve the community if an abandoned name could be
used by a more useful, productive package.

BTW -- as of the security issue -- isn't it the name with domain names?

Someone puts up a website with something at least a little useful on it.

They abandon the domain

A malicious individual puts up up new site with that name that is a clone
of the old one except that it distributed Malware.

I agree that it would be a bit easier to do with PyPi, as it does
specifically distribute software, but the risk is there in any case.

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The mypy package

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 you do pip search mpypi, you get a handful of results, two of which are:

mypy (0.256)   - A wsgi framework
...
mypy-lang (0.2.0)  - Optional static typing for Python

if we're OK with that, we're already done.

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The mypy package

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 issues will
arise.

> Changing this changes the security model of pypi.  If all an attacker has
> to do is wait out an old, but still highly downloaded package... why
> wouldn't they do it?

I'd suggest that a highly downloaded package isn't abandoned. granted, it
may be hard to tell, but I image any package that is frequently, or even
occasionally, downloaded would have *someone* willing to act as maintainer
-- which, at a minimum, is simply replying to an email once a year or so
saying "yes,  this is still an active package"

All that being said -- yes, we wouldn't want to provide an avenue for
someone to post malware to the exact same download-ability as a previously
valid package.

But there has GOT to be a solution to that -- maybe a vetting porcess for
re-using names? This really isn't going to come up all that often.

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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 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(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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:

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


Interesting third case I hadn't considered -- the original author is still
"active", but not actually maintaining the software or accepting help. I
don't think there is anything PyPi policy can do about that -- too bad.

Time for a fork?ï¿½

-CHB


ï¿½
-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½(206) 526-6959ï¿½ï¿½ voice
7600 Sand Point Way NE ï¿½ï¿½(206) 526-6329ï¿½ï¿½ fax
Seattle, WA ï¿½98115 ï¿½ ï¿½ ï¿½ï¿½(206) 526-6317ï¿½ï¿½ main reception

chris.bar...@noaa.gov


___
Distutils-SIG maillist  -
Distutils-SIG@python.orghttps://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

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.


> 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(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

   - Can't just change the rules underneath everyone. If we'd be making a
   package repository today, it would be fine - everything would know the
   rules. There's a huge surprise factor here and a recipe for drama if this
   is changed. If we'd change this perpetuity rule it wouldn't be possible to
   let everyone know about it - read receipts for email don't really exist.
   - Would taking mypy package from random Chinese dude no one seems to
   care about be fair? First release of mypy is in 2009
    while mypy-lang's first commit
   is in 2012. Jukka would had done well if he'd used a different name for
   the project, or resolved the ownership issue back then.
   - Where do you draw the line for "abandoned"? Whom would you allow to
   confiscate ownership? It's impossible to come up with a non-arbitrary
   set of rules.

Plus I'm pretty sure the Chinese dude didn't even read or understood the
mail - we're talking about taking his package while he didn't even reply.
Seriously? Give it time it will sort itself out.
Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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 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.
> 
> Since the spectre of malware has been raised in this thread, I feel I should 
> point out that the reverse is also true.  Although libyaml / pyyaml are 
> "trusted" today, what happens after the inevitable 0-day RCE drops which the 
> author refuses to patch it?  Does PyPI have a responsibility to re-assign the 
> name in that case?  Specifically, YAML does have a heritage 
> 
>  of vulnerabilities, even if this specific instance doesn't.
> 

We don’t currently have much in the way of mechanisms to deal with that. 
Although I could think of a few that we could do which *wouldn’t* require 
handing over the name and which could generalize out to other 
maintenance/abandonment problems as well, like (in order of severity):

* Add a warning on the PyPI page indicating that the project is 
abandoned/unmaintained/etc suggesting they find something else (possibly with 
specific suggestions, like PIL -> Pillow).

* Add some mechanism to pip/PyPI that would allow PyPI to provide a message to 
people installing a particular project (or perhaps a specific version). This 
could also be exposed to authors who want to mark specific versions of their 
project as insecure.

* Delete the files from PyPI or otherwise prevent them from being discovered by 
pip (likely paired with the a warning of some kind on the PyPI page).

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The mypy package


> 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 python"?

-glyph___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Name arbitration on PyPI


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 
community owned.


On 4/18/2016 18:16, Glyph wrote:


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, people could then pin to

Re: [Distutils] The mypy package

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 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 python"?

-glyph


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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 python packages?

Regards,
  Thomas Güttler

--
Thomas Guettler http://www.thomas-guettler.de/
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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;

Domain names are a different system -- you need to maintain your registration.

PyPi names, on the other hand, are all too easy to setup, and then
completely ignore, maybe even forget you used it.

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:

Push a change or update at least once a year (or some other interval).

Or

Respond to some sort of "do you still want this" email. At least once a year.

If neither of these occurs, then we could have a deprecation period.

Details aside, as PyPi continues to grow, we really need a way to
clear out the abandoned stuff -- the barrier to entry for creating a
new name on PyPi is just too low.

This is all too late for MyPy, but it has certainly come up before,
and will again, more and more.

-CHB
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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 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;
>
> Domain names are a different system -- you need to maintain your registration.
>
> PyPi names, on the other hand, are all too easy to setup, and then
> completely ignore, maybe even forget you used it.
>
> 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:
>
> Push a change or update at least once a year (or some other interval).
>
> Or
>
> Respond to some sort of "do you still want this" email. At least once a year.
>
> If neither of these occurs, then we could have a deprecation period.
>
> Details aside, as PyPi continues to grow, we really need a way to
> clear out the abandoned stuff -- the barrier to entry for creating a
> new name on PyPi is just too low.
>
> This is all too late for MyPy, but it has certainly come up before,
> and will again, more and more.
>
> -CHB
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig



-- 
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

This sort of gets to the core of one of the major questions that has to be 
answered before you talk about expiring names and such. Who “owns” a name on 
PyPI? Right now, as implemented, the people who “own” (in terms of ACL) the 
name on PyPI are the owners of said name. In this vein PyPI has traditionally 
been first come first serve on names and generally will not release a name to 
someone else without the current owner’s permission [1]. This leads to 
projects, even popular ones, sometimes falling into abandonment, sometimes even 
when you have a new maintainer willing to step up (as is the case with Ian and 
pyYAML) or in some cases, has already forked the project under another name (as 
is the case with PIL and Pillow). However, this also means that in general, if 
you decide you trust the current owner of something on PyPI, you know that it’s 
not suddenly going to be owned by someone else *unless* the person who you 
previously trusted decides to give it away to them (and thus, implicitly 
transferring the trust you granted them to another person).

So, before we try and think up some mechanism for expiring names, or forcibly 
taking a name from the current owner and giving it to another, we [2] would 
first need to decide that names on PyPI are not owned by the individuals who 
hold the registration, but are instead owned by the community and the current 
individuals are only borrowing them. This would mean that instead of having 
packages wither and get abandoned we could instead transfer them to new 
maintainers who can keep the project going. However, that of course raises new 
questions like:

* Should we only transfer projects to maintainers who want to keep the current 
project going? Such as with PIL or pyYAML?
  - This will be generally less surprising to end users, but it doesn’t solve 
the problem of rarely used packages “blocking” other’s use of the name.

* How do we determine who to give a name to? Surely we shouldn’t hand off a 
package that people are using to the first random passerby who happens to ask 
for it and  we can probably trust Guido not to be malicious (or else we have 
bigger problems ;) ), but how do we determine if someone is to be trusted when 
they inevitably fall somewhere in between?

* The current policy is pretty black and white with only a little bit of grey 
area (what is a “real” package that’s been uploaded to a project, what is a 
malicious package, etc), but moving over to community owned names would open 
things up to a far wider set of grey areas, and who is going to arbitrate when 
a project is abandoned or when it’s “popular” or not?
  - If folks are unaware, npmjs.org  just recently had a bit 
of a kerfuffle over a package on their repository going missing, “left-pad”, 
due to the grey-ness of their policy.
  - The current, fairly rigid policy came around because the PyPI admins 
decided to give what appeared to be an unmaintained library to someone new who 
had forked the library, after the original author hadn’t responded to an email. 
This ended up causing our own kerfuffle when it turned out this person *wasn’t* 
absent and *wasn’t* OK with this. [3].

* If we start giving projects out to other people, what tools should we give 
people to deal with that?
  - The latest version of pip has a mode that allows you to specify a number of 
hashes and it won’t install anything that doesn’t match a hash. That could 
protect end users from installing something inadvertently, but it’s very opt in 
and requires hard pins ``==`` so it’s not likely to get a large uptick.
  - 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, people could 
then pin to

Re: [Distutils] The mypy package

> 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 problem at hand -- mypy has already put itself 
> up as "mypy-lang", an namespace would be pretty much the same thing.
> 
> if you do pip search mpypi, you get a handful of results, two of which are:
> 
> mypy (0.256)   - A wsgi framework
> ...
> mypy-lang (0.2.0)  - Optional static typing for Python
> 
> if we're OK with that, we're already done.

I think there's still a general question here about orphaning packages, but 
maybe in this very specific case a simple name change is in order? 'mypy' never 
really made much sense to me as "python with types"; for many months after I 
started hearing the name, I thought it was some kind of personalizable / 
portable distribution of Python, or maybe a macro system (allowing you to 
personalize python to your tastes).

Might I suggest 'typy' for TYped PYthon?  Nothing shows up in a pip search for 
that just yet.

Just a thought,

-glyph

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

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


Interesting third case I hadn't considered -- the original author is still
"active", but not actually maintaining the software or accepting help. I
don't think there is anything PyPi policy can do about that -- too bad.

Time for a fork?

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

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

Interesting third case I hadn't considered -- the original author is
still "active", but not actually maintaining the software or
accepting help. I don't think there is anything PyPi policy can do
about that -- too bad.

Time for a fork?ï¿½

-CHB

ï¿½
--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR ï¿½ ï¿½ ï¿½ ï¿½ ï¿½ ï¿½(206) 526-6959ï¿½ï¿½ voice
7600 Sand Point Way NE ï¿½ï¿½(206) 526-6329ï¿½ï¿½ fax
Seattle, WA ï¿½98115 ï¿½ ï¿½ ï¿½ï¿½(206) 526-6317ï¿½ï¿½ main reception

chris.bar...@noaa.gov

___
Distutils-SIG maillist -Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

___
Distutils-SIG maillist - Distutils-SIG@python.org

https://mail.python.org/mailman/listinfo/distutils-sig

___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

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

Since the spectre of malware has been raised in this thread, I feel I should 
point out that the reverse is also true.  Although libyaml / pyyaml are 
"trusted" today, what happens after the inevitable 0-day RCE drops which the 
author refuses to patch it?  Does PyPI have a responsibility to re-assign the 
name in that case?  Specifically, YAML does have a heritage 

 of vulnerabilities, even if this specific instance doesn't.

-glyph___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

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

Interesting third case I hadn't considered -- the original author is 
still "active", but not actually maintaining the software or accepting 
help. I don't think there is anything PyPi policy can do about that -- 
too bad.

Time for a fork?

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov 

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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


> 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, people could 
> then pin to  a project without their knowing about it. However we haven’t historically 
> mandated this and there are a lot of projects using date based versions that 
> would b very unhappy (in addition to the fact upper pins often are major 
> contributors to being unable to resolve a version tree of dependencies).


Just want to raise my hand to be counted here among the people that would be 
extremely unhappy if PyPI started mandating semver.

-glyph___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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