Hey, Tres Seaver wrote: [snip]
I take cleaning up deprecation warnings seriously: I want all tests for my packages, for instance, to run without emitting *any* of them. Deprecation warnings have a non-trivial downside: consider the case wher one of *my* downstream users updates Roger's pacakge (e.g., to pick up a critcial security fix, or something). My package has dependencies which allow this (because I don't put hard pins in library packages), but now *my* package now emits warnings, where it didn't before.
You should, and likely are, shipping your package with a recommended list of versions. If your user upgrades beyond that recommended list of versions, then that user knows that any problems that may occur are his own responsibility. A deprecation warning is hardly a disastrous thing to swallow if you're fixing a security bug. I'd also argue that deprecation warnings and security bug fixes should generally not be introduced in the same release, as deprecation should be considered to be a feature change. Anyway, the problem of your downstream users is worse. If you depend on x.y, and Roger makes it so that x.y doesn't depend on a.b anymore, and your downstream user updates to Roger's version of x.y, they will suddenly have breaking *imports* as they happened to be relying on things in a.b which just happened to get pulled in too. [snip]
If we just leave the name importable from the old location, what is hurt? The major downside is that people won't learn about the new location.
Yes, the hurt is that we aren't actually signalling the deprecation of the old location. If the goal is to reduce the dependencies between packages, it's pretty nice if people can follow this in their own packages so that *they* can benefit from less useless dependencies being pulled in as well.
I consider this to be less an issue than the two problems I outline above. Even if the "pending warning" bit works, I still have to add the BBB cruft to my code to future-proof it.
Why? Your downstream users won't see any warnings. Regards, Martijn