Deprecations via warnings don't reliably work anywhere, in general.
If you are a good developer, you'll have extensive unit test coverage and CI. You never see the unit test output (unless they fail) - so warnings go unnoticed.
If you are a bad developer, you have no idea what you are doing and you ignore all warnings unless program crashes.
You can turn warnings into errors with the `-Werror` option. I personally use that in CI runs, along with the `-X dev` option to enable additional runtime checks. Though that wont solve the author's problem, since most Python devs don't use either of those options
In PHP I don’t think there is a native way to convert E_DEPRECATED into E_ERROR, but the most common testing framework has a quick way of doing the same.
> If you are a good developer, you'll have extensive unit test coverage and CI. You never see the unit test output (unless they fail) - so warnings go unnoticed.
In my opinion test suites should treat any output other than the reporter saying that a test passed as a test failure. In JavaScript I usually have part of my test harness record calls to the various console methods. At the end of each test it checks to see if any calls to those methods were made, and if they were it fails the tests and logs the output. Within tests if I expect or want some code to produce a message, I wrap the invocation of that code in a helper which requires two arguments: a function to call and an expected output. If the code doesn't output a matching message, doesn't output anything, or outputs something else then the helper throws and explains what went wrong. Otherwise it just returns the result of the called function:
let result = silenceWarning(() => user.getV1ProfileId(), /getV1ProfileId has been deprecated/);
expect(result).toBe('foo');
This is dead simple code in most testing frameworks. It makes maintaining and working with the test suite becomes much easier as when something starts behaving differently it's immediately obvious rather than being hidden in a sea of noise. It makes working with dependencies easier because it forces you to acknowledge things like deprecation warnings when they get introduced and either solve them there or create an upgrade plan.
When I update python version, python packages, container image, etc for a service, I take a quick look at CI output, in addition to the all the other checks I do (like a couple basic real-world-usage end-to-end usage tests), to "smoke test" whether something not caught by outright CI failure caused some subtle problem.
So, I do often see deprecation warnings in CI output, and fix them. Am I a bad developer?
I think the mistake here is making some warnings default-hidden. The developer who cares about the user running their the app in a terminal can add a line of code to suppress them for users, and be more aware of this whole topic as a result (and have it more evident near the entrypoint of the program, for later devs to see also).
I think that making warnings error or hidden removes warnings as a useful tool.
There was this one library we depended on, it was sort of in limbo during the Python 2 -> 3 migration. During that period is was maintained by this one person who'd just delete older versions when never ones became available. In one year I think we had three or four instances where our CI and unit tests just broke randomly one day, because the APIs had changed and the old version of the library had been yanked.
In hindsight it actually helped us, because in frustrations we ended up setting up our own Python package repo and started to pay more attention to our dependencies.
That's why you, very early on, release code that slows the API down once it has been deprecated. Every place you issue a deprecation warning, you also sleep 60. Problem solved.
>We ended up adding the APIs back and creating a hurried release to fix the issue.
So it was entirely possible to keep the software working with these. Why change/remove them in the first place? Is the benefit of of the new abstraction greater than the downside of requiring everyone using the software to re-write theirs?
OS software maintainers don't like maintaining legacy ugly APIs forever and want to refactor/remove legacy code to keep themselves sane and the project maintainable.
I think this is a valid question for this specific case, but may not always be possible. That said, I think as a user I would probably prefer it if under the hood the old function called the new so they can deprecate the behavior without breaking the API. In that way you can still emit the deprecation warning while also only having one actual code path to maintain.
Wait, does urlib not use semvar? Don't remove APIs on minor releases people. A major release doesn't have to be a problem or a major redesign, you can do major release 400 for all I care, just don't break things on minor releases.
Lots of things not using semvar that I always just assumed did.
As an example, I always knew urllib3 as one of the foundational packages that Requests uses. And I was curious, what versions of urllib3 does Requests pull in?
That is exactly the kind of dependency specification I would expect to see for a package that is using semver: The current version of urllib3 is 2.x, so with semver, you set up your dependencies to avoid the next major-version number (in this case, 3).
So, it seems to me that even the Requests folks assumed urllib3 was using semver.
They article does validly point out that deprecation warnings don't work. Turns out in this day and age that the only thing you can reliably inform about changes is the package manager and its dependency solver, and pip requires semver or similar for that.
Making you distrust updates is absolutely the correct versioning method. Pin your versions in software you care about and establish a maintenance schedule. Trusting that people don't break things unintentionally all the time is extremely naive.
It was dumb and user-hostile to remove an interface for no good reason that just makes it more work for people to update, but everyone not pinning versions needs to acknowledge that they're choosing to live dangerously.
The devil is in the details. It seems `getHeaders` v. `headers` is non-security, non-performance related issue. Why people should spend time fixing these?
Fixing deprecations is unfortunately the lowest prio of any kind of work for majority of the projects. Part of the problem is probably lack of pressure to do so it if the timeline is unclear. What if this is actually never removed? Why going through the pain?
IMO telling "we deprecate now and let's see when we remove it" is counterproductive.
A better way: deprecate now and tell "in 12 (or 24?) months this WILL be removed".
After 12/24 months, cut a new semver-major release. People notice the semver-major through the dependency management tools at some point, an maybe they have a look at changelog.
If they don't, at some point they may want to use a new feature, and finally be incentivised to update.
If there's no incentive other than "do the right thing", it never gets done.
Having said that, I think LLMs are really going to help with chores like this, if e.g. deprecations and migration steps are well documented.
Alternative option: create a codemod CLI that fixes deprecations for the users, doing the right thing automatically. If migration is painless and quick, it's more likely people will do it.
Deprecations in all forms are always a shitshow. There isn’t a particular pattern that “just works”. Anybody that tells you about one, best case scenario, it just worked for them because of their consumer/user not because of the method itself.
The best I have seen is a heavy handed in-editor strike through with warnings (assuming the code is actively being worked on) and even then it’s at best a 50/50 thing.
50% of the developers would feel that using an API with a strike through in the editor is wrong. And the other 50% will just say “I dunno, I copied it from there. What’s wrong with it??”
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.
Wild (and I guess most of the time bad) idea: on top of the warnings, introduce a `sleep` in the deprecated functions. At every version, increase the sleep.
Has this ever been considered?
The problem with warnings is that they're not really observable: few people actually read these logs, most of the time. Making the deprecation observable means annoying the library users. The question is then: what's the smallest annoyance we can come up with, so that they still have a look?
A deprecation warning is not actionable for typical end users. Why don't more warnings include calls to action?
Instead of a warning that says, "The get_widget method in libfoo is deprecated and will be removed by November 30", the warning could say:
"This app uses the deprecated get_widget method. Please report this bug to the app developer. Ask them to fix this issue so you can continue using this app after November 30."
I prefer Go's solution to this problem. Just don't deprecate stuff. And to make that possible, slow down and design stuff you will be willing to support forever.
Deprecations don't work. Don't deprecate stuff without a really really good reason. The new API being cleaner is not a good reason. There are very few good reasons.
If you deprecate something in a popular library, you're forcing millions of people to do work. Waste time that could be used for something better, possibly at a time of your choice, not theirs. It was emitting warnings for 3 years... so you think everyone should have to rewrite their software every 3 years?
Especially for something like this. Only document it in a footnote, mark it as deprecated, etc - but don't remove the alias.
Don't break stuff, unless, to quote a famous work, you think your users are scum. Do you think your users are scum? Why do you hate your users?
Honestly, I think that the author already found (and rejected the solution):
> I could ask for more Python developers to run with warnings enabled, but solutions in the form of “if only we could all just” are a folly.
I get where he's coming from. But the facts are: the language provides a tool to warn users, the library is using that tool, and users are choosing to turn that tool off. That's fine, but then they don't get to complain when stuff breaks without warning. It is the user's responsibility at that point, not the library maintainers'.
I'm very confused on the debate of semver here - the fundamental principle seems very simple, and important.
"give me all updates to my core version that's still compatible"
Semver simply puts a 'protocol' to this - define your major version and off you go.
While in practice you could go and search for each and every library you use to check when/how they do breaking versions, but semver just allows matching a single number across the board - it makes it more consistent and error proof.
Because it's not "error proof". It's not even "more error proof". Relying on updates not breaking if the maintainer doesn’t intend it means relying on software being bug-free, and it should be immediately obvious that that would be a very very stupid thing to believe. Letting software you rely on change on its own is always dangerous no matter how much someone pinky promises that you can trust them to have thought of everything. Semver numbers are determined by humans who aren't oracles and therefore make mistakes all the time about what changes will break something for someone else. It may get people to think a little bit about whether they _think_ they're breaking something, but it's never safe to rely on that judgement because there's a good chance that they're wrong. And given that it's never safe to rely on that judgment, the process of pretending is worse than worthless; the pretense is inherently dangerous, because people start to unthinkingly trust it. If you care about things working, you pin and vendor (npm left-pad) your dependencies and only update a package if you _need_ to and only after explicit evaluation.
And if after reading that you think to yourself, "But BugsJustFindMe, I have unit tests that will catch semver mistakes!" I think you need to ask yourself what your unit tests tell you about semver code that they don't also tell you about non-semver code.
I would absolutely agree with your approach for large-scale saas/highly publicised applications, especially when you have a team/people dedicated to security/versioning.
In small teams where you're focused on building features, being able to rely on semver for non-breaking versions has been very helpful/successful. I personally haven't encountered a breaking feature added to something that shouldn't be.
This also applies to our docker containers, using python 3.13-slim-trixie for example, and letting the patch version sort itself out.
Instead of reverting the updates to appease those who've been ignoring the warnings, a way forward could be to gate the old API behind an environment variable, with a name like "TEMPORARILY_REENABLE_DEPRECATED_APIS". And maybe put an expiry on the variable so it resets occasionally. Otherwise the project just becomes mired and stagnant.
35 comments
[ 5.2 ms ] story [ 60.3 ms ] threadIf you are a good developer, you'll have extensive unit test coverage and CI. You never see the unit test output (unless they fail) - so warnings go unnoticed.
If you are a bad developer, you have no idea what you are doing and you ignore all warnings unless program crashes.
https://docs.phpunit.de/en/12.5/configuration.html#the-failo...
In my opinion test suites should treat any output other than the reporter saying that a test passed as a test failure. In JavaScript I usually have part of my test harness record calls to the various console methods. At the end of each test it checks to see if any calls to those methods were made, and if they were it fails the tests and logs the output. Within tests if I expect or want some code to produce a message, I wrap the invocation of that code in a helper which requires two arguments: a function to call and an expected output. If the code doesn't output a matching message, doesn't output anything, or outputs something else then the helper throws and explains what went wrong. Otherwise it just returns the result of the called function:
This is dead simple code in most testing frameworks. It makes maintaining and working with the test suite becomes much easier as when something starts behaving differently it's immediately obvious rather than being hidden in a sea of noise. It makes working with dependencies easier because it forces you to acknowledge things like deprecation warnings when they get introduced and either solve them there or create an upgrade plan.So, I do often see deprecation warnings in CI output, and fix them. Am I a bad developer?
I think the mistake here is making some warnings default-hidden. The developer who cares about the user running their the app in a terminal can add a line of code to suppress them for users, and be more aware of this whole topic as a result (and have it more evident near the entrypoint of the program, for later devs to see also).
I think that making warnings error or hidden removes warnings as a useful tool.
But this is an old argument: Who should see Python warnings? (2017) https://lwn.net/Articles/740804/
In hindsight it actually helped us, because in frustrations we ended up setting up our own Python package repo and started to pay more attention to our dependencies.
So it was entirely possible to keep the software working with these. Why change/remove them in the first place? Is the benefit of of the new abstraction greater than the downside of requiring everyone using the software to re-write theirs?
Lots of things not using semvar that I always just assumed did.
As an example, I always knew urllib3 as one of the foundational packages that Requests uses. And I was curious, what versions of urllib3 does Requests pull in?
Well, according to https://github.com/psf/requests/blob/main/setup.cfg, it's this:
That is exactly the kind of dependency specification I would expect to see for a package that is using semver: The current version of urllib3 is 2.x, so with semver, you set up your dependencies to avoid the next major-version number (in this case, 3).So, it seems to me that even the Requests folks assumed urllib3 was using semver.
Glory to 0ver: https://0ver.org/
Making you distrust updates is absolutely the correct versioning method. Pin your versions in software you care about and establish a maintenance schedule. Trusting that people don't break things unintentionally all the time is extremely naive.
It was dumb and user-hostile to remove an interface for no good reason that just makes it more work for people to update, but everyone not pinning versions needs to acknowledge that they're choosing to live dangerously.
The devil is in the details. It seems `getHeaders` v. `headers` is non-security, non-performance related issue. Why people should spend time fixing these?
Yes.
IMO telling "we deprecate now and let's see when we remove it" is counterproductive.
A better way: deprecate now and tell "in 12 (or 24?) months this WILL be removed".
After 12/24 months, cut a new semver-major release. People notice the semver-major through the dependency management tools at some point, an maybe they have a look at changelog.
If they don't, at some point they may want to use a new feature, and finally be incentivised to update.
If there's no incentive other than "do the right thing", it never gets done.
Having said that, I think LLMs are really going to help with chores like this, if e.g. deprecations and migration steps are well documented.
Alternative option: create a codemod CLI that fixes deprecations for the users, doing the right thing automatically. If migration is painless and quick, it's more likely people will do it.
The best I have seen is a heavy handed in-editor strike through with warnings (assuming the code is actively being worked on) and even then it’s at best a 50/50 thing.
50% of the developers would feel that using an API with a strike through in the editor is wrong. And the other 50% will just say “I dunno, I copied it from there. What’s wrong with it??”
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.
Has this ever been considered?
The problem with warnings is that they're not really observable: few people actually read these logs, most of the time. Making the deprecation observable means annoying the library users. The question is then: what's the smallest annoyance we can come up with, so that they still have a look?
Instead of a warning that says, "The get_widget method in libfoo is deprecated and will be removed by November 30", the warning could say:
"This app uses the deprecated get_widget method. Please report this bug to the app developer. Ask them to fix this issue so you can continue using this app after November 30."
# Recommended APIs resp.headers.get("Content-Length")
Why inflict this change on tens of millions of users? It's such a nonsense tiny busywork change. Let sleeping dogs lie.
If you deprecate something in a popular library, you're forcing millions of people to do work. Waste time that could be used for something better, possibly at a time of your choice, not theirs. It was emitting warnings for 3 years... so you think everyone should have to rewrite their software every 3 years?
Especially for something like this. Only document it in a footnote, mark it as deprecated, etc - but don't remove the alias.
Don't break stuff, unless, to quote a famous work, you think your users are scum. Do you think your users are scum? Why do you hate your users?
> I could ask for more Python developers to run with warnings enabled, but solutions in the form of “if only we could all just” are a folly.
I get where he's coming from. But the facts are: the language provides a tool to warn users, the library is using that tool, and users are choosing to turn that tool off. That's fine, but then they don't get to complain when stuff breaks without warning. It is the user's responsibility at that point, not the library maintainers'.
"give me all updates to my core version that's still compatible"
Semver simply puts a 'protocol' to this - define your major version and off you go.
While in practice you could go and search for each and every library you use to check when/how they do breaking versions, but semver just allows matching a single number across the board - it makes it more consistent and error proof.
And if after reading that you think to yourself, "But BugsJustFindMe, I have unit tests that will catch semver mistakes!" I think you need to ask yourself what your unit tests tell you about semver code that they don't also tell you about non-semver code.
In small teams where you're focused on building features, being able to rely on semver for non-breaking versions has been very helpful/successful. I personally haven't encountered a breaking feature added to something that shouldn't be.
This also applies to our docker containers, using python 3.13-slim-trixie for example, and letting the patch version sort itself out.