> But I am genuinely curious about the use cases behind allowing package > authors to have absolute freedom, by the way - there's something I am > not understanding. Is this because it is thought that otherwise > developers won't use PyPI at all?
In general, PyPI prefers to not set policies when we can avoid it. There was a long discussion on what package names should be allowed (generally and also about specific package names), and the conclusion was always that package authors can put any content on PyPI as long as it's Python-related, and not spam or illegal. It's only consequential that there shouldn't be a policy on whether a package can be deleted. I *personally* think you are exaggerating your case. If you are using a package, avoid sticking to a specific version of the software, and instead write the package in a way that will work with many versions of the library. If the library is too unstable, don't use it at all. If the library has an incompatible change, report it as a bug; if the author can bring convincing arguments why there must be that change, cope with it. IOW, just don't use old versions when newer versions are available and maintained. > It can't be that it's considered good practice to change the contents > of an older release, or to remove one, right? Right. And it can't be considered good practice to rely on software that follows bad practice, right? Don't use software that deletes old releases while making unjustified incompatible changes in new releases, or otherwise doesn't provide clear backwards compatibility statements and migration strategies. > It seems positively > dangerous to allow people to arbitrarily replace old packages with new > content - installation instructions will be totally broken, and there > are some security risks as well. Again, you, as the package user, need to evaluate these risks. If you trust the author, you don't need to worry. If you don't trust the author, either don't use it, or take countermeasures (like inspecting all code before using it, and using hashsums in automated deployments). Regards, Martin _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
