At 10:39 PM 7/4/2011 +0200, Laura Creighton wrote:
Idea:
When somebody wants to remove a package, they get a message
'are you sure you want to do this? Other people may be relying
on this package. Wouldn't it be kinder to them to give them
a depreciation period?' And then, either kick in a depreciation
period -- during which time if Martijn dl the package e gets told
that it is deprecated, and is going away in XXX (reasonable time to
be worked out later, for the purposes of this article, say 6 weeks).
Then in 6 weeks the package automatically goes away. Or if the
author says, "Hell yes, delete the thing now!" than that happens
instead.
This would be nice if there were a way to communicate to automated
installation tools about this deprecation, in such a way that it
reached people who could do something about it... and somehow
magically motivated them to act.
In practice, such a message would be mostly ignored by users until it
actually broke their builds, at which time they will actually pay
attention to what it says on the PyPI page.
(Or, more likely, they will complain to somebody upstream of them who
will then look at the PyPI page.)
To put it another way, if you are removing a package because you
really don't want people using it unless they have an excellent and
*considered* reason for doing so (e.g. a version with security
issues), you're not going to get anybody to STOP using that version
unless you break their mindless automated build. That's the only way
you're going to get their (motivated) attention pointed at whatever
needs changing.
That doesn't mean deprecation isn't a good idea, though. Certainly,
the build tools out there could be updated to flag warnings about
deprecated packages, and people with projects big enough to have QA
(i.e., the folks who most likely care about this issue anyway)
probably WOULD pay attention to deprecation warnings.
(I don't think I'd object to using a deprecation process as the
normal way of removing a package, but on principle I believe an
author should have the ability to remove their uploads for any reason
or no reason.)
_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
