Hi there, On Mon, Jul 4, 2011 at 10:39 PM, Laura Creighton <[email protected]> wrote: > 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.
This would, I imagine, be an improvement. Anyway, it's not that this is happening a *lot*; it's in fact extremely rare. This is what makes it so tempting to use PyPI in the way I (and many others) are using it. Perhaps with a warning like this it would not happen at all anymore. But you can't rely on it. > 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. A communication channel for package maintainers to tell package users "hey, this has a really serious security bug!" or "this is deprecated" would be useful. The package homepage on PyPI can be used for that, of course, though perhaps isn't perfect as people who are using your package indirectly might not ever see it. But even if we had a deprecation mechanism, it wouldn't exactly solve my use case, as it'd still mean that I would need to distribute my own backups of all packages I'm using to be able to reliably replicate an installation somewhere else. Sometimes this is not a burden, and often it's wise to do so anyway, but frequently (say with a bunch of geographically distributed developers) it is a lot more convenient to be able to rely on a central infrastructure. It's not like doing this for dependencies is unheard of either - people are relying on content distribution networks for Javascript dependencies, for instance. Anyway, not changing or removing old releases just seems like the Right Thing To Do in general in software development; I'd like the tools to support this. Regards, Martijn _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
