[deleted]
We Have to Talk About Flask
11–20 of 116 posts
Re: We Have to Talk About Flask
#12I 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 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.
Re: We Have to Talk About Flask
#13https://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 problem is that breaking changes in widely-used packages are disrespectful to your users. See Rich Hickey’s Spec-ulation
Re: We Have to Talk About Flask
#14Shouldn'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?
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.
Re: We Have to Talk About Flask
#15The 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.
Re: We Have to Talk About Flask
#16Can anyone challenge the author's assertion that the 3.0 release doesn't bring any improvements?
Re: We Have to Talk About Flask
#17https://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 problem is that breaking changes in widely-used packages are disrespectful to your users. See Rich Hickey’s Spec-ulation
Would it not work to specify the version when installing the packages?
Re: We Have to Talk About Flask
#18https://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 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.
Re: We Have to Talk About Flask
#19Earlier quoted context omitted.
The problem is that breaking changes in widely-used packages are disrespectful to your users. See Rich Hickey’s Spec-ulation
Would it not work to specify the version when installing the packages?
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.
Re: We Have to Talk About Flask
#20Earlier quoted context omitted.
The problem is that breaking changes in widely-used packages are disrespectful to your users. See Rich Hickey’s Spec-ulation
Would it not work to specify the version when installing the packages?
No, because your users basically have to upgrade eventually, unless you commit to provide bug fixes (security especially) for every major version.