[Catalog-sig] disallowing the removal of packages?

["Martin v. Löwis"]

> 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