[Catalog-sig] (counter-)Proposal: Discouraging removal of packagers and revisions (Was Re: disallowing the removal of packages?)
faassen at startifact.com
Fri Jul 15 16:55:47 CEST 2011
On 07/15/2011 03:24 PM, Jim Fulton wrote:
> 1. I think if package maintainers actually knew that removing old
> revisions did harm, most would not delete revisions or packages unless
> they thought it was necessary. I think most people who remove old
> revisions do so for cleanliness, not appreciating that there is a
> 2. I think a lot of people were turned off by the mandatory nature of
> the original proposal. (I now regret my +1 of that proposal, made in
> support of the sentiment behind it, but not taking into consideration
> how it runs counter to Python culture.)
Sure, I already indicated a +1 earlier.
I tried to sketch out the use cases behind my proposal but people
focused on what turned them off.
So thinking about this more, what about an extra feature that focuses on
What I'm interested in is the following:
* reducing the incidence of suddenly removed packages (the message might
* being aware that packages are removed
Others also expressed an interest in having the following:
* having a way to deprecate old releases or whole packages
So what if we provided communication channels for that?
if a package or release is removed by an author, they could be asked to
give a reason ("botched upload!", "legal reasons"), whatever.
Then there'll be a feed which shows recent deletions along with the
reasons. There'd be some machine readable components in this feed too.
Also useful for tools would be way to access the total list of all
This could also be expanded to a "deprecation message". Instead of
removing a package, an author can add a deprecation message to a
package. This could also be on a feed.
This way we have a communication channel where we can be informed about
what's going on. In response both humans as well as automated tools
could take action. You could for instance have a scanning tool which
looks at installed packages and tells you which ones are deprecated or
It doesn't offer the same guarantees as a perpetual mirror would, so it
doesn't quite solve the same use cases. But it would make it possible
for people to properly collaborate and communicate about this kind of thing.
I'm not proposing that any of the existing client-side tools are
adjusted to support any of this.
tldr: we've got a feed and index for packages. what about a feed and
index for removals and deprecations?
More information about the Catalog-SIG