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
_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
