9 ms·

We Have to Talk About Flask

43 points by carc1n0gen 3y ago

hiatus 3y ago
Shouldn't the tutorial author be specifying a version in the tutorial?
- miguelgrinberg 3y ago
  Normally tutorials ask readers to install latest versions of everything. If you have to provide a version for every package used in a tutorial, it means that every time any of such dependencies releases a new version the tutorial has to be updated. I guess it is possible for a blog post, but how can I update my books or my videos?
  - ska 3y ago
    Surely you should specify at least the major version, and/or the version you tested on. Otherwise you are throwing out the entire point of semantic (or semantic-like) versioning.
  - hiatus 3y ago
    If there is a major version upgrade to a dependency, you would have to update the tutorials if there is a backwards-incompatible change.
  - adocomplete 3y ago
    There lies the issue. Installing the latest version of everything for a newly published tutorial, or one that is a few months old, you'll typically get the experience you'd expect. But trying to follow along to a tutorial that is old and asks you to install latest version of anything likely means that you won't get far. As someone that's written many tutorials, I've been guilty of using "latest" but have been much more proactive here to call out specific versions used at the top of my articles. Nothing worse than getting through half a tutorial to find out something has completely changed.
  - CBLT 3y ago
    Pip has special syntax for "compatible version" `package~=X.Y`, how about you just always use that in tutorials? The people watching tutorial videos need all the help they can get, why not give them hygienic dependency practices?
    - ehutch79 3y ago
      next you'll demand people put dates on tutorials, like people even want to know if a tutorial is 10 years old.
  - itishappy 3y ago
    > how can I update my books or my videos? You shouldn't need to. How/why are you writing tutorials for major versions that don't exist yet? > `pip install flask` installs the latest version, which is 2.0 at the time of writing
  - dragonwriter 3y ago
    > Normally tutorials ask readers to install latest versions of everything. They shouldn't. They should be doing specified versions, either precise or bounded to the degree you trust the dependency suppliers semver compliance. > If you have to provide a version for every package used in a tutorial, it means that every time any of such dependencies releases a new version the tutorial has to be updated. No. It doesn't. You document what version is covered. You then have the choice to update that or not. OTOH, failing to specify dependency versions means every time abmny of the dependencies releases a new version, the tutorial potentially breaks, which is much worse than working fine but not using a newer version of a dependency when you are not, in either case, using any new features of the new version. (Because if you aren’t upgrading the tutorial, its not covering features of the new version, even if the loosely-specified packages mean uses will pull in the new versions.)
JoeAltmaier 3y ago
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.
- dekhn 3y ago
  The cure is to put a test on it (beyonce rule), and make the test passing required for release. And do rapid rollbacks (within 1 day) if bad releases are made.
  - JoeAltmaier 3y ago
    If you own all the code, sure. But big things (OS, framework etc) have code squirreled away all over the world.
  - paulddraper 3y ago
    Flask puts a test on someone else's unmaintained pacakge?
    - dekhn 3y ago
      In this case, I would expect that the author of this post (who, IIUC is also the creator of flask), should have a test case that trips/fails within a day of the tutorial becoming invalid. At least then he knows the tutorial is going to fail for users. I was burned by flask/werkzeug enough times to completely avoid flask unless absolutely neccessary.
dekhn 3y ago
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.
- supriyo-biswas 3y ago
  I have designed a personal tutorial authoring system that does exactly this, forcing you to include expected outputs in your article, which act as unit tests. However the idea kinda went nowhere as the main issue with writing tutorials is that you gotta compete with websites with poorly written, ad-riddled articles that are somehow ranked on top by Google; and furthermore the end is near for such tutorial websites anyway given the proliferation of ChatGPT/GPT4.
- sdenton4 3y ago
  I used to work on Sage, a math super package, which used 'doc tests' - documentation strings contained executable examples with expected outputs, and the test systems would run them all and check that they worked.
  - JimDabell 3y ago
    Python has this built in: https://docs.python.org/3/library/doctest.html https://docs.python.org/3/library/doctest.html
- miguelgrinberg 3y ago
  Explain to me how you would apply this concept to a book. Or to a YouTube video. I'm not unreasonable, I get that things have to change from time to time. I just think maintainers should think more carefully when they introduce breaking changes. The cost to them is very high!
  - dekhn 3y ago
mmnfrdmcx 3y ago
The flask-login package should have limited its dependencies to flask<3.0, that's what major versions are for.
- miguelgrinberg 3y ago
  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.
  - JimDabell 3y ago
    > You pip install Flask, and you get 3.0 The learning material should specify a major version so this doesn’t happen.
  - lcnPylGDnU4H9OF 3y ago
    > trivial reasons This is a bit like a No True Scotsman argument. It says that there are reasons for what happened but they didn't have a Good Reason. Why are their reasons so particularly trivial? > try to learn Flask in a world like the one you describe This seems moot if the Flask maintainers are using semantic versioning correctly. I'd probably look into it and think that Flask-Login maintainers should have limited their Flask version if they were going to step away from maintenance. If someone else wants to pick it up they can fork it or try to get in touch with the old maintainers to get access to the central repo.
  - ilyt 3y ago
    framework developer isn't responsible for random tutorials going out of date because abandoned plugin wasn't updated in 2+ years
usrbinbash 3y ago
https://semver.org/ https://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?
- fiddlerwoaroof 3y ago
  The problem is that breaking changes in widely-used packages are disrespectful to your users. See Rich Hickey’s Spec-ulation
  - bckr 3y ago
    Would it not work to specify the version when installing the packages?
    - seanc 3y ago
      Only to an extent. I can't think of a language environment where each package can have its own version of a dependency. Python certainly isn't one. So if you want any of the Flask 3.0 features you have to take the new Werkzeug, and see Flask-Login break.
      - fiddlerwoaroof 3y ago
        Node lets every package have its own versions of dependencies. But, imo, it’s better (less time spent fixing upgrade breakage/incentive to pick stable dependencies) in the long run to depend on latest and always update, fixing breakage as you go and only locking versions in CI so you can deploy a known bundle.
        rgoulter 3y ago
        Of "Frequently update dependencies to latest" or "don't have to modify code which depends on others", you only get to pick one. If you're frequently updating to latest, you're on the bleeding edge; sometimes things will bleed more than others. If you're stable, you might not have the latest and greatest all the time. The attitude of expecting to always have the latest and greatest, but never have anything break, all while not paying for the effort, seems absurd to me.
pphysch 3y ago
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.
- bscphil 3y ago
  Right. The closest analogy I can think of is answers on Stack Overflow. Usually those answers apply to the latest version of whatever software they're about, but this means many of them will eventually be out of date. You can find plenty of answers with code that assumes Python 2, written by authors who had no idea there was going to be a Python 3. And that's okay. It's not a bad thing for answers to sometimes go out of date. A really good answer might specify the major version of software it references, just to be future proof, but that isn't strictly necessary since anyone can just add a new answer and old answers can be edited (on Stack Overflow). For tutorials, it's much more incumbent on them not to mislead users into following an old tutorial, since most people will want to start with the latest version. Put a banner at the top that says "this is a tutorial for Flask 2.x, the latest version of Flask at the time of writing", and/or pin versions in your installation instructions.
sergioisidoro 3y ago
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.
- kyawzazaw 3y ago
  poetry is very hard to setup
  - bandyaboot 3y ago
    Could you expand on this? I recently started a new project and decided to use poetry for the first time. It didn’t seem difficult at all to me.
- kennywinker 3y ago
  > 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.
  - sergioisidoro 3y ago
    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.
jollyllama 3y ago
Can anyone challenge the author's assertion that the 3.0 release doesn't bring any improvements?
- miguelgrinberg 3y ago
  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.
  - jollyllama 3y ago
    The nuance escapes me, but I'm sorry to put words in your mouth. I'm still interested in any countervailing opinions on this particular detail.
  - ilyt 3y ago
    But it (presumably) brings benefits to the authors. Sometimes you need to cut the zipties and install the air filter properly...
deleted 3y ago
[deleted]
Forgotthepass8 3y ago
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.
rs_rs_rs_rs_rs 3y ago
"Don't make breaking changes because they break my book" is peak entitlement.
paulddraper 3y ago
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.
Saphyel 3y ago
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
- amanzi 3y ago
  Flask is a minimal web framework that relies on its ecosystem of packages and tutorials to keep it current and relevant. So yes, this is a problem for Flask if key packages that are recommended in just about all tutorials do not keep up to date.
  - Saphyel 3y ago
    Technically wrong. Parallels only develops Flask and they want to keep Flask as minimal as possible, they don't even want to move away from the legacy optparse for Click, so this kind of "minimal work". Key packages are developed by the community so lack of understanding or no cooperation with Parallels it's not really a Flask issue. Unfortunately the only solutions for this are: * Join Parallels and try to change things. * Use different package, there's plenty web frameworks. * Understand better semver, and python should try to promote this, or move away from semver to calendar releases like Ubuntu/Jetbrains
amanzi 3y ago
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.
pil0u 3y ago
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.
JodieBenitez 3y ago
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.
nicoz3 3y ago
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.
- acdha 3y ago
  It’s not missing the point, it’s that the author of this screed lead with whining about a project breaking compatibility on a major release. Since most of the software world has collectively agreed that’s how it’s supposed to work, whatever else they wrote is going to be buried because the author chose to start the post that way. Since they picked a deliberately provocative title there’s little chance that’s going to be a salvageable conversation.
  - mixmastamyk 3y ago
    Woosh.
bigdog42 3y ago
Looks like the changes are already in FlaskLogin https://github.com/wangsha/flask-login/commit/6d1b352dd5106ebdee5d784017c2513591c68db6#diff-cebbed5b3a6ea1d4cdbac299e8472381a0c9e41ce2b9831f6497d7dfc6998bd9L14 https://github.com/wangsha/flask-login/commit/6d1b352dd5106e... but not yet released. This is more an issue with versioning
nickjj 3y ago
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 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/ https://buildasaasappwithflask.com/
regularfry 3y ago
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.

43 points by carc1n0gen 3y ago

hiatus 3y ago

Shouldn't the tutorial author be specifying a version in the tutorial?

miguelgrinberg 3y ago
Normally tutorials ask readers to install latest versions of everything. If you have to provide a version for every package used in a tutorial, it means that every time any of such dependencies releases a new version the tutorial has to be updated. I guess it is possible for a blog post, but how can I update my books or my videos?
- ska 3y ago
  Surely you should specify at least the major version, and/or the version you tested on. Otherwise you are throwing out the entire point of semantic (or semantic-like) versioning.
- hiatus 3y ago
  If there is a major version upgrade to a dependency, you would have to update the tutorials if there is a backwards-incompatible change.
- adocomplete 3y ago
  There lies the issue. Installing the latest version of everything for a newly published tutorial, or one that is a few months old, you'll typically get the experience you'd expect. But trying to follow along to a tutorial that is old and asks you to install latest version of anything likely means that you won't get far. As someone that's written many tutorials, I've been guilty of using "latest" but have been much more proactive here to call out specific versions used at the top of my articles. Nothing worse than getting through half a tutorial to find out something has completely changed.
- CBLT 3y ago
  Pip has special syntax for "compatible version" `package~=X.Y`, how about you just always use that in tutorials? The people watching tutorial videos need all the help they can get, why not give them hygienic dependency practices?
  - ehutch79 3y ago
    next you'll demand people put dates on tutorials, like people even want to know if a tutorial is 10 years old.
- itishappy 3y ago
  > how can I update my books or my videos? You shouldn't need to. How/why are you writing tutorials for major versions that don't exist yet? > `pip install flask` installs the latest version, which is 2.0 at the time of writing
- dragonwriter 3y ago
  > Normally tutorials ask readers to install latest versions of everything. They shouldn't. They should be doing specified versions, either precise or bounded to the degree you trust the dependency suppliers semver compliance. > If you have to provide a version for every package used in a tutorial, it means that every time any of such dependencies releases a new version the tutorial has to be updated. No. It doesn't. You document what version is covered. You then have the choice to update that or not. OTOH, failing to specify dependency versions means every time abmny of the dependencies releases a new version, the tutorial potentially breaks, which is much worse than working fine but not using a newer version of a dependency when you are not, in either case, using any new features of the new version. (Because if you aren’t upgrading the tutorial, its not covering features of the new version, even if the loosely-specified packages mean uses will pull in the new versions.)

JoeAltmaier 3y ago

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.

dekhn 3y ago
The cure is to put a test on it (beyonce rule), and make the test passing required for release. And do rapid rollbacks (within 1 day) if bad releases are made.
- JoeAltmaier 3y ago
  If you own all the code, sure. But big things (OS, framework etc) have code squirreled away all over the world.
- paulddraper 3y ago
  Flask puts a test on someone else's unmaintained pacakge?
  - dekhn 3y ago
    In this case, I would expect that the author of this post (who, IIUC is also the creator of flask), should have a test case that trips/fails within a day of the tutorial becoming invalid. At least then he knows the tutorial is going to fail for users. I was burned by flask/werkzeug enough times to completely avoid flask unless absolutely neccessary.

dekhn 3y ago

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.

supriyo-biswas 3y ago
I have designed a personal tutorial authoring system that does exactly this, forcing you to include expected outputs in your article, which act as unit tests. However the idea kinda went nowhere as the main issue with writing tutorials is that you gotta compete with websites with poorly written, ad-riddled articles that are somehow ranked on top by Google; and furthermore the end is near for such tutorial websites anyway given the proliferation of ChatGPT/GPT4.
sdenton4 3y ago
I used to work on Sage, a math super package, which used 'doc tests' - documentation strings contained executable examples with expected outputs, and the test systems would run them all and check that they worked.
- JimDabell 3y ago
  Python has this built in: https://docs.python.org/3/library/doctest.html https://docs.python.org/3/library/doctest.html
miguelgrinberg 3y ago
Explain to me how you would apply this concept to a book. Or to a YouTube video. I'm not unreasonable, I get that things have to change from time to time. I just think maintainers should think more carefully when they introduce breaking changes. The cost to them is very high!
- dekhn 3y ago

mmnfrdmcx 3y ago

The flask-login package should have limited its dependencies to flask<3.0, that's what major versions are for.

miguelgrinberg 3y ago
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.
- JimDabell 3y ago
  > You pip install Flask, and you get 3.0 The learning material should specify a major version so this doesn’t happen.
- lcnPylGDnU4H9OF 3y ago
  > trivial reasons This is a bit like a No True Scotsman argument. It says that there are reasons for what happened but they didn't have a Good Reason. Why are their reasons so particularly trivial? > try to learn Flask in a world like the one you describe This seems moot if the Flask maintainers are using semantic versioning correctly. I'd probably look into it and think that Flask-Login maintainers should have limited their Flask version if they were going to step away from maintenance. If someone else wants to pick it up they can fork it or try to get in touch with the old maintainers to get access to the central repo.
- ilyt 3y ago
  framework developer isn't responsible for random tutorials going out of date because abandoned plugin wasn't updated in 2+ years

usrbinbash 3y ago

https://semver.org/ https://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?

fiddlerwoaroof 3y ago
The problem is that breaking changes in widely-used packages are disrespectful to your users. See Rich Hickey’s Spec-ulation
- bckr 3y ago
  Would it not work to specify the version when installing the packages?
  - seanc 3y ago
    Only to an extent. I can't think of a language environment where each package can have its own version of a dependency. Python certainly isn't one. So if you want any of the Flask 3.0 features you have to take the new Werkzeug, and see Flask-Login break.
    - fiddlerwoaroof 3y ago
      Node lets every package have its own versions of dependencies. But, imo, it’s better (less time spent fixing upgrade breakage/incentive to pick stable dependencies) in the long run to depend on latest and always update, fixing breakage as you go and only locking versions in CI so you can deploy a known bundle.
      - rgoulter 3y ago
        Of "Frequently update dependencies to latest" or "don't have to modify code which depends on others", you only get to pick one. If you're frequently updating to latest, you're on the bleeding edge; sometimes things will bleed more than others. If you're stable, you might not have the latest and greatest all the time. The attitude of expecting to always have the latest and greatest, but never have anything break, all while not paying for the effort, seems absurd to me.

pphysch 3y ago

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.

bscphil 3y ago
Right. The closest analogy I can think of is answers on Stack Overflow. Usually those answers apply to the latest version of whatever software they're about, but this means many of them will eventually be out of date. You can find plenty of answers with code that assumes Python 2, written by authors who had no idea there was going to be a Python 3. And that's okay. It's not a bad thing for answers to sometimes go out of date. A really good answer might specify the major version of software it references, just to be future proof, but that isn't strictly necessary since anyone can just add a new answer and old answers can be edited (on Stack Overflow). For tutorials, it's much more incumbent on them not to mislead users into following an old tutorial, since most people will want to start with the latest version. Put a banner at the top that says "this is a tutorial for Flask 2.x, the latest version of Flask at the time of writing", and/or pin versions in your installation instructions.

sergioisidoro 3y ago

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.

kyawzazaw 3y ago
poetry is very hard to setup
- bandyaboot 3y ago
  Could you expand on this? I recently started a new project and decided to use poetry for the first time. It didn’t seem difficult at all to me.
kennywinker 3y ago
> 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.
- sergioisidoro 3y ago
  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.

jollyllama 3y ago

Can anyone challenge the author's assertion that the 3.0 release doesn't bring any improvements?

miguelgrinberg 3y ago
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.
- jollyllama 3y ago
  The nuance escapes me, but I'm sorry to put words in your mouth. I'm still interested in any countervailing opinions on this particular detail.
- ilyt 3y ago
  But it (presumably) brings benefits to the authors. Sometimes you need to cut the zipties and install the air filter properly...

deleted 3y ago

[deleted]

Forgotthepass8 3y ago

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.

rs_rs_rs_rs_rs 3y ago

"Don't make breaking changes because they break my book" is peak entitlement.

paulddraper 3y ago

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.

Saphyel 3y ago

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

amanzi 3y ago
Flask is a minimal web framework that relies on its ecosystem of packages and tutorials to keep it current and relevant. So yes, this is a problem for Flask if key packages that are recommended in just about all tutorials do not keep up to date.
- Saphyel 3y ago
  Technically wrong. Parallels only develops Flask and they want to keep Flask as minimal as possible, they don't even want to move away from the legacy optparse for Click, so this kind of "minimal work". Key packages are developed by the community so lack of understanding or no cooperation with Parallels it's not really a Flask issue. Unfortunately the only solutions for this are: * Join Parallels and try to change things. * Use different package, there's plenty web frameworks. * Understand better semver, and python should try to promote this, or move away from semver to calendar releases like Ubuntu/Jetbrains

amanzi 3y ago

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.

pil0u 3y ago

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.

JodieBenitez 3y ago

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.

nicoz3 3y ago

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.

acdha 3y ago
It’s not missing the point, it’s that the author of this screed lead with whining about a project breaking compatibility on a major release. Since most of the software world has collectively agreed that’s how it’s supposed to work, whatever else they wrote is going to be buried because the author chose to start the post that way. Since they picked a deliberately provocative title there’s little chance that’s going to be a salvageable conversation.
- mixmastamyk 3y ago
  Woosh.

bigdog42 3y ago

Looks like the changes are already in FlaskLogin https://github.com/wangsha/flask-login/commit/6d1b352dd5106ebdee5d784017c2513591c68db6#diff-cebbed5b3a6ea1d4cdbac299e8472381a0c9e41ce2b9831f6497d7dfc6998bd9L14 https://github.com/wangsha/flask-login/commit/6d1b352dd5106e... but not yet released. This is more an issue with versioning

nickjj 3y ago

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 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/ https://buildasaasappwithflask.com/

regularfry 3y ago

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.