from Hacker News

We Have to Talk About Flask

by carc1n0gen on 10/19/23, 3:34 PM with 114 comments

by usrbinbash on 10/19/23, 4:53 PM

    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?

by dekhn on 10/19/23, 4:38 PM
I 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.
by mmnfrdmcx on 10/19/23, 4:53 PM
The flask-login package should have limited its dependencies to flask<3.0, that's what major versions are for.
by sergioisidoro on 10/19/23, 5:02 PM
The 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.
by pil0u on 10/19/23, 5:52 PM
Despite the "it's your fault" vibe towards Miguel, I have to say: thank you Miguel!!
Your tutorial was a turning point for me 4 years ago, the care you take to write and help people is very precious. My ability to write modest web apps takes its roots in your free online materials, I am grateful for that.
by JoeAltmaier on 10/19/23, 4:20 PM
Any older product will fall into disrepair, simply due to the decreased attention old features get. Plus the years of accumulated of references to any particular feature, that would take years to track and put right whenever it changes.
Not sure there's any cure.
I hit this (OP) issue myself. Solved it somehow, don't remember, just another glitch in the neverending series of glitches that are open-source lack-of-support and obsolete documentation.
Just today, noticed Steam tutorial videos generally use some obsolete version of their website tools. Have to fish around, find where the menus etc are, they sure aren't where the video says they are.
Business as usual.
by pphysch on 10/19/23, 4:57 PM
It seems unreasonable to expect anything that relies on "version:latest" to not break upon a major version change.
What makes a tutorial different than any other software process, in this context?
Your tutorial was written and functions for a particular version of a software. Pin that version. It's the straightforward thing to do.
Frankly, I would be insulted if I was miseducated by a tutorial that purports to be up to date, but was actually written for a old major version. Learning obsolete techniques, missing best-practices.
by nickjj on 10/20/23, 2:47 AM
I've been maintaining my Build a SAAS App with Flask video course[0] for 8 years. It has gone from Flask pre-1.0 to 2.3 and has been recorded twice with tons of incremental updates added over the years to keep things current.
In my opinion tutorial creators should pin their versions so that anyone taking the course or going through the tutorial will have a working set up that matches the video or written material.
I'm all for keeping things up to date and do update things every few months but expecting anyone can install any version doesn't tend to work well for tutorials because sometimes bumping a minor version requires a code change or covering new concepts. As a tutorial consumer it's frustrating when the content doesn't match the source code unless it's something simple like a version bump.
As a tutorial creator it's your responsibility to ensure things work which ultimately leads to doing everything in your power to remove time as a variable. You can commit a frozen dependency file which locks everything. I sleep pretty well at night knowing things will work tomorrow. Before I did that I had all sorts of things break over the years due to some dependency of a dependency introducing a backwards incompatible change. Now it's predictable and I can control when it's safe to update a set of packages.
I've held off upgrading Flask to 3.0 and Python 3.12 due to these open issues with popular 3rd party packages https://github.com/nickjj/docker-flask-example/issues/17. I'm sure new releases will get pushed in due time. When they are good to go then I'll add a new video update and all is well for everyone. Maintainers can work at their own pace, I can verify everything works in production and then roll it into the course and folks taking the course get an up to date version that's been proven to work.
[0]: https://buildasaasappwithflask.com/
by paulddraper on 10/19/23, 5:22 PM
This article uses such odd phrasing.
> Flask 3.0 was released on September 30th, 2023, along with a parallel 3.0 release of Werkzeug
> That day, the Flask-Login extension, one of the most popular of all Flask extensions, stopped working
Every major release BY DEFINITION will break things.
And breaking "that day"? It's really "that second" or "that nanosecond" by the same standard.
---
You can complain about one of two things:
1. Flask did not need to developed a backwards incompatible 3.0 release, but could have developed a backwards compatible 2.* release.
2. Flask-login is too slow to release a version compatible with the newest version of Flask released 3 weeks ago.
But this blog post presents it in...such a weird way.
by amanzi on 10/19/23, 5:56 PM
This is a wider issue with Flask and the surrounding ecosystem, and is also why I switched to Django a couple of years ago. I don't recall which package it was specifically, but there was a commonly used security package that was recommended by lots of blogs and tutorials, but the maintainer no longer wanted to maintain it but also didn't want to let anyone else contribute. So it led to another developer forking it and adding a '2' to the end of the name just to keep it current. This wouldn't have been such a big issue if the package didn't add really important security features to Flask, but due to the minimal nature of Flask it really depends on having a well-managed ecosystem of packages. My takeaway was that I felt I couldn't rely on Flask for an application that required features that weren't in the main Flask package itself.
But just wanted to also say, that the main reason I enjoyed working with Flask at the time, was due to Miguel's excellent mega-tutorial. Again, that speaks to the value of having a good ecosystem to support your solution. Flask have ultimately shot themselves in the foot by releasing something they must have known would break a huge number of sites, without bringing the community along with them on the journey.
by hiatus on 10/19/23, 3:46 PM
Shouldn't the tutorial author be specifying a version in the tutorial?
by nicoz3 on 10/19/23, 7:22 PM
By reading many of the comments here, it looks like that you are missing the point (maybe you are not a Flask user): it would be great if Flask would only introduce breaking changes in major releases. Unfortunately, many things break with minor releases too. We develop a framework built with Flask, and it is very painful. We always pin Flask< minor version (not major). This is unfortunately happening with other software too. The community should really align and stick to SemVer.
by regularfry on 10/20/23, 2:03 PM
It seems to me that the problem here is that everyone directly depends on pypi. The Debian model would be to introduce another repository layer, explicitly to say "everything you install from this repository will work together". Hoping to achieve the same effect with version numbers is a fool's errand, especially when nobody agrees what version numbers mean.
by Saphyel on 10/19/23, 5:50 PM
So this is yet another post about how terrible is the python ecosystem with the versions.
The author of the post seems unfamiliar with the meaning of a major release.
maxcountryman (author of flask-login) doesn't know how to pin down versions.
I'm not a big fan of Flask to be honest but this doesn't seem a problem from them. I'd rather blame maxcountryman , the author of the post or pip for this case
by jollyllama on 10/19/23, 5:02 PM
Can anyone challenge the author's assertion that the 3.0 release doesn't bring any improvements?
by rs_rs_rs_rs_rs on 10/19/23, 5:19 PM
"Don't make breaking changes because they break my book" is peak entitlement.
by JodieBenitez on 10/19/23, 6:03 PM
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.
by bigdog42 on 10/19/23, 8:48 PM
Looks like the changes are already in FlaskLogin
https://github.com/wangsha/flask-login/commit/6d1b352dd5106e...
but not yet released.
This is more an issue with versioning
by Forgotthepass8 on 10/19/23, 5:08 PM
This occurs all the time when using LLMs for code due to the variety of versions of each lib in their training data (which is typically years old already)
Some sort of automatic functionality to find deltas in libraries (even just crude function inspection between versions) and detect/remap them (or roll back versions) might solve that and issues like this.