Hence why I prefer Django over Flask any day. Less moving parts, more stability. I even upgraded Django apps from one major version to another with little to no change to the apps.
We Have to Talk About Flask
61–70 of 116 posts
Re: We Have to Talk About Flask
#62https://semver.org/ Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes So what exactly is the issue here?
I think the author learned for first time of his life that framework plugins need to keep up with framework changes.
2 years (flask 2.0 release) should be plenty for deprecation notice.
Re: We Have to Talk About Flask
#63Earlier quoted context omitted.
I'd say the respect towards the users is displayed by the frequency of breaking changes and the overall time to migrate, through deprecation warnings and at least security maintenance of older versions. Sometimes things need to change. Speaking of that, flask 2 was released in May 21. I can't really complain about some breaking changes every 2 years or so. That's almost like a linux distribution.
> I'd say the respect towards the users is displayed by the frequency of breaking changes and the overall time to migrate, through deprecation warnings and at least security maintenance of older versions. Sometimes things need to change. A change that brings new added value to users is a case where the change needs to be made, yes. But the article's point is that the Flask changes don't seem to be doing that. They're…
Throwing the crust away and refactoring stuff also "doesn't add new features" but it needs to be done to keep codebase good.
> giving users no added value to compensate for the time and effort required to deal with the change
... the users of free software. That didn't bother to find&replace one method in their plugin code.
Re: We Have to Talk About Flask
#64The problem stems from how fragmented dependency management in python is. Most tutorials use `pip install something` without much care for pinning versions. Yes, it makes it easier for new programmers: They can skip learning a dependency management tool like poetry, or pipenv. But then these things happen. Blame the tutorial makers and the dependency maintainers, not the Flask team.
> Blame the tutorial makers and the dependency maintainers I'd blame the python community as a whole, for not driving everybody (flask team, tutorial makers, dependency maintainers, etc) towards pinned versions. This is a well-established problem in any environment where you write code that has dependencies. Strict use of semver, and tools that respect those conventions, would solve MOST of this.
Well, they are trying... For tooling they tried to get this done well with pipenv, but (imho) failed for how slow and clunky it is. I really tried to like pipenv, but now I just go for poetry.
But one thing that needs to be acknowledged is how difficult it is to coordinate a space with so many stakeholders (eg. Conda and Anaconda for Windows), and how python got so engrained in the sys admin (installing tools with pip.) that undoing that is a monstrous task [1]
[1] The other day my ansible playbooks stopped working because packages that you used to be able to install globally with pip, should now be installed through the package managers (eg. jsondiff should now be installed as apt-get install pyton3-jsondiff). Exactly to push people to use virtual environments where you can better manage depedencies.
Re: We Have to Talk About Flask
#65Earlier quoted context omitted.
>But the Flask-Login team is not actively developing the extension anymore. So they should tie the development to an extension that isn't in further development?
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…
Adding code into your framework to support abandonware plugins is the exact opposite of better solution
Re: We Have to Talk About Flask
#66I have long advocated the idea that online tutorials should have unit tests: there should be a daily build that loads the tutorial, extracts the code bits, runs them, and reports a failure if a dependency broke the tutorial. And those tutorials should have the ability to force rollbacks of minor point releases that break backwards compatibility. Tutorials should be pinned to major point releases.
That reminds me my history with Ruby. Got to the famous "blog in 15 minutes" tutorial, used the stuff that comes with OS, nothing worked, didn't touch ruby again till I had to.
Re: We Have to Talk About Flask
#67The flask-login package should have limited its dependencies to flask<3.0, that's what major versions are for.
So consider what happens when you try to learn Flask in a world like the one you describe. You pip install Flask, and you get 3.0. Next chapter asks you to install Flask-Login, and now you are forced to downgrade Flask. What you are saying makes sense when there are important reasons to break compatiblity. But I expect the Flask side to love their users a bit more and not break their code for trivial reasons.
framework developer isn't responsible for random tutorials going out of date because abandoned plugin wasn't updated in 2+ years
Re: We Have to Talk About Flask
#68Can anyone challenge the author's assertion that the 3.0 release doesn't bring any improvements?
My assertion is that none of the refactorings in the 3.0 release bring a benefit to the community. I did not imply that the entire 3.0 release is void of improvements.
But it (presumably) brings benefits to the authors. Sometimes you need to cut the zipties and install the air filter properly...
Re: We Have to Talk About Flask
#69The problem stems from how fragmented dependency management in python is. Most tutorials use `pip install something` without much care for pinning versions. Yes, it makes it easier for new programmers: They can skip learning a dependency management tool like poetry, or pipenv. But then these things happen. Blame the tutorial makers and the dependency maintainers, not the Flask team.
Python dependency management certainly has many problems, but I don't think this is one of them--or at least, it's not a problem unique to Python. The practice of tutorials/docs/guides installing unpinned/latest versions is incredibly common in most (all?) scripting languages' communities. While that's not great, I don't think it has anything to do with the fragmentation of Python's dependency management.
Well, if there would be one accepted dependency management tool / environment, it would make things easier at least.
For example, despite all the problems of JS, new devs don't need to create a virtual environment and activate it all the time. They don't need to manually add lines to a requirements.txt, or pick a tool like poetry or pip env [1]
[1] Edit: ok they have to pick yarn/npm, but even those share a common file base formate - package.json
Re: We Have to Talk About Flask
#70https://semver.org/ Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes So what exactly is the issue here?
The post's point is that an API change is a very big deal, to be used only when the older version just can't work anymore or the newer version offers something much better. But the Flask team seems to have a much lower bar on what justifies the change. So the author feels unhappy he has to update a bunch of projects for no good reason.
The post would have a point if the Flask team treated this like a minor release (2.x -> 2.x+0.1) instead of a major (2.x -> 3.x) and hadn't issued a deprecation warning.