[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