[Catalog-sig] an immutable mirror of PyPI

Martijn Faassen faassen at startifact.com
Fri Jul 15 16:36:28 CEST 2011

Hi there,

On 07/06/2011 05:54 PM, M.-A. Lemburg wrote:
>> This is not a good reason, IMHO. You can go on with new versions and a
>> new name, maybe you could want to deprecate the old package, but it's
>> not a good reason to remove it.
> I think undoing mistakes in package names is a very
> good reason to remove them. As package author you don't want such
> mistakes to stay on the net forever, if you can avoid it.

I don't understand the "you don't want such mistakes to stay on the net 
forever" line of argumentation. As a package author, once you release 
something to the internet, you can assume it'll stay on the net. This is 
already true. So this is an unfixable problem that we're not making 
worse by having an immutable mirror.

>>>   * legal action (copyright, trademark, DMCA, license issues, etc)
>>>   * removal of malicious packages (e.g. script kiddy stuff in
>>>    setup.py)
>>>   * seriously broken builds (e.g. that cause users to lose data)
>> This is would make a good reason for package removal, but not for
>> version reassignment. I.E. if I delete version 0.4.3 because it
>> deleted my /usr instead of /usr/share/mylib/content, then I would be
>> right at removing it, but there's no point in allowing any other
>> package to take back 0.4.3. It's simply gone.
> I'm not sure I understand what you want to say. I wasn't talking
> about version reassignment in the above cases.

Well, it restricts the use cases. The use case "re-release Foo 3.0 but 
with different contents" doesn't seem to be necessary to tackle the 
above, just plain removal.

So a friendly perpetual mirror would need to be able to handle delete 
requests but not re-upload requests.

>>>   * reassigning package names (not sure whether that's possible with
>>>    PyPI, but it certainly happens in the wild every now and then)
>> I'm not sure about what you mean here.
> Author A releases a package X, then drops the idea and removes
> the package, freeing up the name for others to use. Later on,
> author B uses the name X for something different and creates
> a new package X with a new set of releases.

I wonder by the way whether PyPI supports the "dropping package name 
forever" use case now.

I think a lot is to be gained if you assume package names to be unique 

For instance: allowing this would be a major security risk: I release 
package X. Package X is used by people. Then I drop the name. Someone 
else completely unrelated comes along, creates package with the same 
name, and uploads evil code. Hilarity ensues.

I know the answer already: "Just don't use packages by people who will 
drop the name at a nebulous point in the future then!" :)

Yes, allowing this follows from the "developers should have total 
freedom" goal that is apparently the main driver behind PyPI's use 
cases, but there are also "security please" and "repeatability" use cases.



More information about the Catalog-SIG mailing list