Tres Seaver wrote:
> 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.
> 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
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -