[Catalog-sig] an immutable mirror of PyPI

Terry Reedy tjreedy at udel.edu
Mon Jul 18 22:47:58 CEST 2011


On 7/16/2011 6:54 AM, Martijn Faassen wrote:

> So I have use cases: I can release code that relies on releases that can
> disappear or can be replaced. I think this is bad for repeatability and
> security. I'd like to see some improvements made. How would we make
> these improvements? I've so far proposed three ideas:
>
> * PyPI not throwing away things after a grace period. Almost universally
> rejected idea
>
> * an additional service, a mirror, that offers some repeatability
> guarantees. Removal would need to go through channels, implying some
> kind of custodianship I think people here are wary about.
>
> * better communication channels: a list of what's been removed, a list
> of what's been deprecated. I can then write tools that help me maintain
> my projects. It's not the same as the above ideas: old projects can
> still break at the whim of people whose code I depend on, but it'll at
> least help manage this issue.

If packages have dependency list, then pypi could keep a ref count for 
each package and either not allow deletion of packages with a + count or 
require admin approval or at least inform the developer 'You are about 
to delete a package that other programs depend on: you sure you want to 
delete it?' followed 'Are you really really sure? Can we keep the file 
for a few months and give users a warning?"

-- 
Terry Jan Reedy



More information about the Catalog-SIG mailing list