Deprecations via warnings don't work for Python libraries

The secret trick I've used on rare occasion, but when necessary, is the "ten second rule."

Users don't notice a deprecation warning. But they might notice adding a "time.sleep(10)" immediately at the top of the function. And that gives them one last grace period to change out their software before it breaks-breaks.

This will just waste CI compute and not solve anything.

It's worked in the past. But it does require someone at your org to care that CI times are spiking, which is not always a thing you can rely upon.

In addition: if CI is the only place the issue shows up, and never in a user interaction... Why does that software exist in the first place? In that context, the slowdown may be serving as a useful signal to the project to drop the entire dependency.

ETA: To be clear, I don't do this as a substitute for a regular deprecation cycle (clear documentation, clear language-supported warnings / annotations, clear timeline to deprecate); I do it in addition before the final yank that actually breaks end-users.

Are you saying you wouldn't notice if your CI suddenly started taking twice as long, ten times as long, a hundred times as long to run?

This is so much worse than just making the breaking change.

It depends on how we define "worse."

A breaking change causes a full-stop to a service.

An intentional slowdown lets the service continue to operate at degraded performance.

I concur that it's less clear for debugging purposes (although any reasonable debugging infrastructure should allow you to break and see what function you're in when the program hangs; definitely not as clear as the program crashing because the called function is gone, however).

A breaking change in a dependency doesn’t cause a full-stop to a service at all. The old version continues to work. Making subtly harmful changes so that new broken versions sneak in is just a bad idea and totally unnecessary.

> A breaking change in a dependency doesn’t cause a full-stop to a service at all

From the article:

"We still received feedback from users that this removal was unexpected and was breaking dependent libraries."

I think we may be assuming different floors on service maintainer competency; with so many users pulling in dependencies across an arbitrarily-wide version window with no testing, such changes do break services.

It’s not necessary to cater to the absolute least competent end user to begin with, but inserting slowdown bugs does not even achieve that. (Note that the bit about the breaking of dependent libraries you’re quoting is still not actually a service being affected.)