[Catalog-sig] an immutable mirror of PyPI
faassen at startifact.com
Fri Jul 15 16:36:28 CEST 2011
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
>>> * 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