71–80 of 116 posts
Earlier quoted context omitted.
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.
Earlier 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. 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.
Earlier quoted context omitted.
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.
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…
Anyways, in my experience, if you routinely use the latest and greatest versions of dependencies, over time you find that you stop using dependencies that make this painful.
Anyways, I’m fine with accidental breakage. Deliberately choosing instability in the form of a major version release seems irresponsible for packages at the base of an entire ecosystem. (Absent some critical security issue that your users would have to address anyways as happened with log4j)
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.
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!
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 softw…
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.
> 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.
You can lock Python versions.
But people by default, people type pip/npm/apt/yum install without the version.
Nothing unique to Python.
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.
https://github.com/wangsha/flask-login/commit/6d1b352dd5106e...
but not yet released.
This is more an issue with versioning
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?
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.)