Deprecations via warnings don't work for Python libraries

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.

> Fixing deprecations is unfortunately the lowest prio of any kind of work for majority of the projects.

... and the right answer to that is to make it entirely their problem.

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

In this case, the warnings said exactly what release would remove the API. Didn't help.

> Why going through the pain?

Because you're not a feckless irresponsible idiot? I don't think it's an accident that the projects they said didn't react were an overcomplicated and ill-designed management layer for an overcomplicated and ill-designed container system, a move-fast-and-break-things techbro company, and what looks to be a consolation project for the not-too-bright.

You probably get an extra measure of that if you're operating in the Python ecosystem, which is culturally all about half-assed, 80-percent-right-we-hope approaches.

The right answer is to remove it when you say you're going to remove it, and let them pick up the pieces.

It also helps if you design your API right to begin with, of course. But this is Python we're talking about again.