[Catalog-sig] disallowing the removal of packages?
faassen at startifact.com
Mon Jul 4 21:56:15 CEST 2011
If I hand a project that relies on 100 dependencies to someone, I
prefer not to have to hand private copies of all those 100
dependencies to that someone as well just in case a package maintainer
removes a version from PyPI. It just makes my life harder. I'd prefer
to rely on a centrally maintained infrastructure in that case.
I could, in theory, make my own backup arrangement where I basically
replicate PyPI to keep all previous releases online forever, and then
rely on that. If you place your packages on PyPI, your packages would
end up on this backup arrangement of mine.
But it seems odd not to do the right thing at the source. So came to
discuss it there.
So anyway, I'm discussing use cases. Let's get back to that.
I think you have a very different view of what PyPI is for, or could
be for, than I do.
Is PyPI a service for Python developers to find reusable code? Is PyPI
a hosting site for Python developers to publish their code online?
Does PyPI support integrators? Or is it more like a hosting site where
people can do whatever they want? How much is this like, say, Debian
and how much is this like a developer's website?
> (Certainly, if it looks like your proposal will be adopted, I would be strongly motivated to *immediately* remove any package from PyPI > that I thought I might need to remove later, but would be unable to if the proposal were implemented!)
[why taking such an aggressive stance?]
Clearly you have a concept of which packages or releases you might
need to remove later: could you state your motivations behind removing
packages or releases? Perhaps there's a use case I missed in the
above, or perhaps, again, you have a different philosophy of what PyPI
More information about the Catalog-SIG