31–40 of 116 posts
Can anyone challenge the author's assertion that the 3.0 release doesn't bring any improvements?
Shouldn't the tutorial author be specifying a version in the tutorial?
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?
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-supp…
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.
But big things (OS, framework etc) have code squirreled away all over the world.
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…
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.
Earlier quoted context omitted.
The problem is that breaking changes in widely-used packages are disrespectful to your users. See Rich Hickey’s Spec-ulation
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.
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 not making breaking changes in order to introduce new features that add value for users. They're making breaking changes just because they feel like it, giving users no added value to compensate for the time and effort required to deal with the change. That's not respecting users.
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.
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.
Earlier quoted context omitted.
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?
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?
The 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.
The learning material should specify a major version so this doesn’t happen.
Earlier quoted context omitted.
The problem is that breaking changes in widely-used packages are disrespectful to your users. See Rich Hickey’s Spec-ulation
>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?
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.
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.