Well said.

IMO, package names shouldn't be reused.  Also, IMO, we have a
namespace problem, for which there's a common solution that we avoid
(domain based names, which can also be reused, but ...).

OTOH, here's an idea. What if in addition to the project name, we also
assigned a unique id. When a package was added to a consuming project,
we'd store both the packages name, and it's project id.  When looking
up a package, we'd supply both the project name and id.  If a name was
reused, the new project with the same name would have a new project id
and wouldn't be confused with the old one.  We could even still server
the old project's released without advertising them.  This way, if we
did decide to reuse a name, we could do so pretty safely.

Jim


On Wed, Jul 13, 2016 at 12:54 AM, Donald Stufft <don...@stufft.io> wrote:
>
>> On Jul 12, 2016, at 4:45 PM, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote:
>>
>> My feeling is that there should be a "dead man's switch" sort of mechanism 
>> for this.  Require manual intervention from at least one package owner at 
>> least once a year.  I believe if you dig around in the archives there's been 
>> quite a bit of discussion around messaging to package owners and that sort 
>> of thing - and the main sticking point is that someone needs to volunteer to 
>> do the work on Warehouse.  Are you that person? :)
>
>
> I suspect any change like this will require some sort of PEP or something 
> similar to it. It’s something that I think is going to hard to get just right 
> (if it’s something we want to do at all).
>
> Software can be “finished” without needing more releases, and sometimes 
> projects stop getting updates until the maintainer has more time (or a new 
> maintainer comes along). An example is setuptools which had no releases 
> between Oct 2009 and Jun 2013. Another nice example is ``wincertstore`` which 
> has had two releases one in 2013 and one in 2014 and is one of the most 
> downloaded projects on PyPI. It doesn’t need any updates because it’s just a 
> wrapper around Windows APIs via ctypes.
>
> Another thing we need to be careful about is what do we do once said dead 
> man’s switch triggers? We can’t just release the package to allow anyone to 
> register it, that’s just pointing a security shaped footgun at the foot of 
> every person using that project? It doesn’t make sense to block new uploads 
> for that project since there’s no point to disallowing new uploads. Flagging 
> it to allow someone to “take over” (possibly with some sort of review) has 
> some of the security shaped footguns as well as a problem with deciding who 
> to trust with a name or not.
>
> —
> Donald Stufft
>
>
>
> _______________________________________________
> 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

Reply via email to