[ilyt]

Or remove it altogether, warn people for years about deprecation, then remove all of them. Which they did.

More net lines removed too.

But hey, it annoyed Man That Is Bad At Dependency Management and Wrote A Book About It so it must be bad!

[pdonis]

> Or remove it altogether

Which, as the GP of my original post in this subthread argued, and I agree, is not respectful to your users. Importing the function from the Python standard library is a one-liner, hardly an arduous burden.

[ilyt]

Right, then commit that one line fix to the plugin

[pdonis]

Yes, for each of the umpteen number of packages that depends on Flask. Instead of Flask just doing it one time and avoiding that breaking change altogether.

Open source is supposed to be a community. Forcing a breaking change like this on all their dependencies that they could have avoided with a one-line import statement is, IMO, not very good behavior as a community member.

[usrbinbash]

> Forcing a breaking change

No one is forcing a breaking change on anyone.

    a) PIP usually retains past versions
    b) A python package can specify it's dependencies, including their version, as hard requirements
    c) virtualenvs exist

If a packages maintainer doesn't want to change his code to support some changes in some_dependency-v4.2, he can specify that the package requires some_dependency-v2.1 or whatever other existing version he is happy with.

If he doesn't do that, and instead specifies only `some_dependency`, that signals to the package management software that the package works with the `@latest` version of that dependency. The onus to make sure that is, and continues to be, the case in code, is on the maintainer of the package, not the maintainer of the dependency, period.

And no, this is not "disrespectful". This doesn't go against any sense of community in FOSS. This is established practice in software development and package maintenance.

[fiddlerwoaroof]

This is a pretty naive take that assumes the only relevant parties are the various library authors. The real issue here is the hours and hours of useless maintenance work breaking changes routinely force on anyone writing software with the supposedly "modern" tech stacks. Sure, maybe this change adds a minute of work for someone using flask. How much time does it save flask's maintainers? More than 1 minute * the number of people using flask? Being more hesitant about breaking changes as a industry would eliminate hundreds of person-years of basically useless maintenance work.

[usrbinbash]

> Being more hesitant about breaking changes as a industry

... would lead to even more outrage, because we tried that in the past. And the result were "rotting libraries", that became unmaintainable, incomprehensible, and riddled with hard to track and harder to fix bugs, because they had to drag along code that was often more than a decade old, kicking and screaming, just so libadbandonedsincebronzeage.so wouldn't have to issue an update.

So no, we should have breaking changes.

We should keep libraries vital and get rid of old code. We shouldn't drag along stuff just because we can. We have established procedures to deal with this, and with good reason.