6 ms·

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

by theamk 11mo ago

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.

SethMLarson 11mo ago
Author here! Agreed that are different levels of "engaged" from users, which is okay. The concerning part of this finding is that even dependent users that I know to be highly engaged didn't respond to the deprecation warnings, so they're not working for even the most engaged users.
eternityforest 11mo ago
Why is it that CI tools don't make warnings visible? Why are they ignored by default in the first place? Seems like that should be a rather high priority.
- metadat 11mo ago
  Most of the time they don't matter and aren't an immediate problem. The Business doesn't care about warnings, they want working software NOW.
- bluGill 11mo ago
  It isn't that easy. If you have a new warning on upgrade you probably want to work on it "next week", but that means you need to ignore it for a bit. Or you might still want to support a really old version without the new API and so you can't fix it now.
  - Hizonner 11mo ago
    > If you have a new warning on upgrade you probably want to work on it "next week", but that means you need to ignore it for a bit. So you create a bug report or an issue or a story or whatever you happen to call it, and you make sure it gets tracked, and you schedule it with the rest of your work. That's not the same thing as "ignoring" it.
    - bluGill 11mo ago
      And you always have something more important/interesting to do and so never get around to it.
      - Hizonner 11mo ago
        ... which means that when the axe falls, the results are 100 percent your fault.
- michaelt 11mo ago
  > Why is it that CI tools don't make warnings visible? A developer setting up CI decides to start an ubuntu 24.04 container and run 'apt-get install npm' This produces 3,600 lines of logging (5.4 log lines per package, 668 packages) and 22 warnings (all warnings about man page creation being skipped) Then they decide "Nobody's going to read all that, and the large volume might bury important information. I think I'll hide console output for processes that don't fail." Now your CI doesn't show warnings.
optionalsquid 11mo ago
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
- Y-bar 11mo ago
  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. https://docs.phpunit.de/en/12.5/configuration.html#the-failondeprecation-attribute https://docs.phpunit.de/en/12.5/configuration.html#the-failo...
rimunroe 11mo ago
> 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.
ploxiln 11mo ago
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. But this is an old argument: Who should see Python warnings? (2017) https://lwn.net/Articles/740804/ https://lwn.net/Articles/740804/
Hizonner 11mo ago
If you are a good developer, you consider warnings to be errors until proven otherwise.
- hiq 11mo ago
  What does a good developer do when working in a codebase with hundreds of warnings? Or are you only considering a certain warnings?
  - Hizonner 11mo ago
    Why does your codebase generate hundreds of warnings, given that every time one initially appeared, you should have stamped it out (or specifically marked that one warning to be ignored)? Start with one line of code that doesn't generate a warning. Add a second line of code that doesn't generate a warning...
    - stackskipton 11mo ago
      Because most people are working at Failure/Feature factories where they might work on something and at last minute, they find out something is now warning. If they work on fixing it, the PM will screaming about time slippage and be like "I want you to work on X, not Y which can wait". 2 Years later, you have hundreds of warning.
      - Hizonner 11mo ago
        You found that out at the last minute. So then you did a release. It's no longer the last minute. Now what's your excuse for the next release? If your management won't resource your project to the point where you can assure that the software is correct, you might want to see if you can find the free time to look for another job. You'll have to do that anyway when they either tank the company, or lay you off next time they feel they need to cut more costs.
    - hiq 11mo ago
      It's rare that I work on a project I myself started. If I start working on an existing codebase, the warnings might be there already. Then what do I do? I'm also referring to all the warnings you might get if you use an existing library. If the requirements entail that I use this library, should I just silence them all? But I'm guessing you might be talking about more specific warnings. Yes I do fix lints specific to my new code before I commit it, but a lot of warnings might still be logged at runtime, and I may have no control over them.
mrweasel 11mo ago
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.
wang_li 11mo ago
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.
- skeledrew 11mo ago
  A solid idea. There should be a package for this.

by theamk 11mo ago

SethMLarson 11mo ago

Author here! Agreed that are different levels of "engaged" from users, which is okay. The concerning part of this finding is that even dependent users that I know to be highly engaged didn't respond to the deprecation warnings, so they're not working for even the most engaged users.

eternityforest 11mo ago

Why is it that CI tools don't make warnings visible? Why are they ignored by default in the first place? Seems like that should be a rather high priority.

metadat 11mo ago
Most of the time they don't matter and aren't an immediate problem. The Business doesn't care about warnings, they want working software NOW.
bluGill 11mo ago
It isn't that easy. If you have a new warning on upgrade you probably want to work on it "next week", but that means you need to ignore it for a bit. Or you might still want to support a really old version without the new API and so you can't fix it now.
- Hizonner 11mo ago
  > If you have a new warning on upgrade you probably want to work on it "next week", but that means you need to ignore it for a bit. So you create a bug report or an issue or a story or whatever you happen to call it, and you make sure it gets tracked, and you schedule it with the rest of your work. That's not the same thing as "ignoring" it.
  - bluGill 11mo ago
    And you always have something more important/interesting to do and so never get around to it.
    - Hizonner 11mo ago
      ... which means that when the axe falls, the results are 100 percent your fault.
michaelt 11mo ago
> Why is it that CI tools don't make warnings visible? A developer setting up CI decides to start an ubuntu 24.04 container and run 'apt-get install npm' This produces 3,600 lines of logging (5.4 log lines per package, 668 packages) and 22 warnings (all warnings about man page creation being skipped) Then they decide "Nobody's going to read all that, and the large volume might bury important information. I think I'll hide console output for processes that don't fail." Now your CI doesn't show warnings.

optionalsquid 11mo ago

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

Y-bar 11mo ago
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. https://docs.phpunit.de/en/12.5/configuration.html#the-failondeprecation-attribute https://docs.phpunit.de/en/12.5/configuration.html#the-failo...

rimunroe 11mo ago

> 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.

ploxiln 11mo ago

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. But this is an old argument: Who should see Python warnings? (2017) https://lwn.net/Articles/740804/ https://lwn.net/Articles/740804/

Hizonner 11mo ago

If you are a good developer, you consider warnings to be errors until proven otherwise.

hiq 11mo ago
What does a good developer do when working in a codebase with hundreds of warnings? Or are you only considering a certain warnings?
- Hizonner 11mo ago
  Why does your codebase generate hundreds of warnings, given that every time one initially appeared, you should have stamped it out (or specifically marked that one warning to be ignored)? Start with one line of code that doesn't generate a warning. Add a second line of code that doesn't generate a warning...
  - stackskipton 11mo ago
    Because most people are working at Failure/Feature factories where they might work on something and at last minute, they find out something is now warning. If they work on fixing it, the PM will screaming about time slippage and be like "I want you to work on X, not Y which can wait". 2 Years later, you have hundreds of warning.
    - Hizonner 11mo ago
      You found that out at the last minute. So then you did a release. It's no longer the last minute. Now what's your excuse for the next release? If your management won't resource your project to the point where you can assure that the software is correct, you might want to see if you can find the free time to look for another job. You'll have to do that anyway when they either tank the company, or lay you off next time they feel they need to cut more costs.
  - hiq 11mo ago
    It's rare that I work on a project I myself started. If I start working on an existing codebase, the warnings might be there already. Then what do I do? I'm also referring to all the warnings you might get if you use an existing library. If the requirements entail that I use this library, should I just silence them all? But I'm guessing you might be talking about more specific warnings. Yes I do fix lints specific to my new code before I commit it, but a lot of warnings might still be logged at runtime, and I may have no control over them.

mrweasel 11mo ago

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.

wang_li 11mo ago

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.

skeledrew 11mo ago
A solid idea. There should be a package for this.