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
forever.
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.
Regards,
Martijn
_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
