The issue with Flask-Login isn't even a functionality change. Flask just decided to stop making a particular function available in their namespace and now wants you to import it from the Python standard library instead.
A better solution for a case like this would be to import the function from the Python standard library into the Flask namespace, so old code would still work. Then it wouldn't matter that Flask-Login is no longer actively maintained.
Also, as the article notes, Flask-Login is by no means the only Flask-using Python package that was broken by this change. Are all of those other packages no longer actively maintained? I doubt it.
> Flask-Login is by no means the only Flask-using Python package that was broken by this change
Package maintenance also means to keep up with changes in the packages dependencies. If I don't do that, that's my problem, not the dependencies.
If I want to fix a certain version as my requirement, I can do so. Every major package system, including the ones used in Python, allow this. If I don't want that, then I need to keep my package maintained, and that means keeping an eye on what my dependencies do. That's part of package maintenance, simple as that.
There is no onus on the dependencies maintainers to care about whether I do my maintenance or not.
> There is no onus on the dependencies maintainers to care about whether I do my maintenance or not.
There's no "onus" on Flask to do anything they don't want to do. But if Flask forces every package that depends on them to fix a breaking change that they could have avoided with a one-line import statement, I would argue that is not very respectful of all those other package maintainers.
The reverse would be that every package that depends on flask forces it to make all future changes dependent on whether or not they break someones code. Which obviously isn't a sustainable model for software development.
> I would argue that is not very respectful of all those other package maintainers.
Define what is "respectful" then?
The flask team announces changes. They deprecate things. They use deprecation warnings. They use major versions correctly. They honor well established good practices in software development, to give package maintainers the opportunity to react to changes early.
Please, do explain: What else is required to meet whatever definition of "respectful" we are talking about here?
There’s also no onus on me to continue using packages that force me to spend valuable time fixing their breaking changes. My rule of thumb for dependencies is that, once I have to fix three or four breaking changes, the cost of switching to a more stable alternative or writing my own becomes more worth it.
There’s also the option of releasing a package called something like flask2_compatibility that monkeypatches flask3 to work with flask2
> A better solution for a case like this would be to import the function from the Python standard library into the Flask namespace, so old code would still work.
For as long as the functionality does not change. Which it didn't when the function was removed; the Python standard library function had the same functionality as the former Flask function that was removed.
They wouldn't have needed to add any code. They could have just changed their implementation of the function to an import of it from the Python standard library. That would be a net reduction in code size.
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.
This is what I'm scratching my head at too. Why would it be a good thing for any OSS maintainer to slow themselves down for packages that don't want to fix deprecation warnings?
That would break every single module that is compliant with flask 3.x and imports it with `import flask`. This simply isn't justified by the "benefit" of some old packages not having to change a single line of code.
Yes, maybe in hindsight it would have been beneficial to put the major version of some packages (flask is far from the only one) directly into the package name, as a workaround for pythons inability to deal with multiple versions of the same module under the same name in one environment. But python works as it does, `import flask` is how god-knows how many projects use it, so that's how the show runs, period.
If some package requires a certain version, it can pin that version in its `setup.py`. If a project requires a certain version it can pin that version in it's `requirements.txt`. If an environment requires a certain version, the admin can create a virtualenv.
As Rich Hickey argues in the talk I referenced, semver and version pinning is a problem not a solution. I’ve written lots of code using only stable dependencies that are stable over the span of decades, and it’s just a much nicer ecosystem to be able to rely on.
> semver and version pinning is a problem not a solution
Almost every practice in software development is a compromise that wouldn't be necessary if some decision in the past were different.
I think I agreed with you somewhere in this thread, that version-names (flask1, flask2, ...) are a better solution than major versions.
However, `flask` as an import name isn't going to go away. That is simply a reality and we have to work with it, because alot of projects rely on this. The same is true for tens of thousands of important software packages all over the OSS landscape.
So we can argue all day and then some over "what if"s...it won't change the status quo that exists, and in that state, semver is a good compromise that solves way more problems than it introduces.
A better solution for a case like this would be to import the function from the Python standard library into the Flask namespace, so old code would still work. Then it wouldn't matter that Flask-Login is no longer actively maintained.
Also, as the article notes, Flask-Login is by no means the only Flask-using Python package that was broken by this change. Are all of those other packages no longer actively maintained? I doubt it.