[Catalog-sig] disallowing the removal of packages?

Michael Foord fuzzyman at gmail.com
Mon Jul 4 21:48:38 CEST 2011

On 4 July 2011 20:25, Georg Brandl <g.brandl at gmx.net> wrote:

> Am 04.07.2011 20:59, schrieb P.J. Eby:
> > At 05:41 PM 7/4/2011 +0200, Martijn Faassen wrote:
> >>I'd argue d) and e) are not up to the package maintainer to decide
> >>but to the person who integrates this package into their system.
> >
> > Sure...  but that doesn't mean the package maintainer is obligated to
> > support the integrator in that decision.
> >
> >
> >>The person who integrates the package is the one who will need to
> >>make the judgment call to continue to use old unsupported or broken
> >>stuff. Integrators should be allowed to make such decisions in their
> >>own time at their own convenience; the package developer shouldn't
> >>be able to force such decisions by removing an old release.
> >
> > Then the package integrator should darn well keep their own copy
> > instead of relying on it still being downloadable from a public
> > server.  Not keeping a file uploaded is not equal to forcing anybody
> > else to do anything.
> >
> > Note that there is nothing in your proposal that keeps a package
> > maintainer from simply never uploading packages to PyPI in the first
> > place...  and is likely to have the perverse effect of encouraging
> > package authors who are concerned about this issue to make other
> > hosting arrangements.
> >
> > (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!)
> >
> > In short, this proposal is asking PyPI to do a job that is properly
> > done by either the web archive or your private backups.  -1.
> I have to agree.  Any hosting service that doesn't allow me to remove
> uploaded content looks extremely fishy to me.

Sourceforge for a long time had a policy against removing any released
source packages (and may still have that policy as far as I know).

All the best,


> I think this list has already discussed the issue of people using PyPI
> as a dependency for deployment in production, and recommended the use
> of private package mirrors.
> Georg
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig



May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20110704/7d6438f9/attachment-0001.html>

More information about the Catalog-SIG mailing list