Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We Have to Talk About Flask

blog.miguelgrinberg.com

Post reply on HN
Print view View original

41–50 of 116 posts

Re: We Have to Talk About Flask

#41

Post by kennywinker »

sergioisidoro wrote: post #15

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.

Re: We Have to Talk About Flask

#42

Post by zbowling »

vharuck wrote: post #30
usrbinbash wrote: post #7

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?

The post's point is that an API change is a very big deal, to be used only when the older version just can't work anymore or the newer version offers something much better. But the Flask team seems to have a much lower bar on what justifies the change. So the author feels unhappy he has to update a bunch of projects for no good reason.

What stops folks from sticking with the last version of the last major point release? Do the flask folks not provide security or other update to older major point releases? Sometimes in the software lifecycle, you need to refactor and move on from older API designs. Even keeping old APIs around adds cruft, testable surface area you have to support, and slows down everything and adds risk with shipping software over time. Android, iOS, GTK, half the javascript and C++ libraries in the world, etc pop in into my head and all will break some amount in a major version update.

Re: We Have to Talk About Flask

#44

Post by paulddraper »

vharuck wrote: post #30
usrbinbash wrote: post #7

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?

The post's point is that an API change is a very big deal, to be used only when the older version just can't work anymore or the newer version offers something much better. But the Flask team seems to have a much lower bar on what justifies the change. So the author feels unhappy he has to update a bunch of projects for no good reason.

tl;dr The author things that Flask should release a 2.* and have no breaking changes.

Re: We Have to Talk About Flask

#45

Post by SteveNuts »

skrebbel wrote: post #25
usrbinbash wrote: post #7

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?

The issue is that releasing breaking changes sucks for your users. A numbering scheme doesn’t really make it suck any less.

Breaking changes are fine (and a lot of times completely necessary) as long as they are expected _for what you're trying to do_.

The numbering scheme is meant to give predictability to breaking changes or backwards compatibility, so if followed correctly, it absolutely should make it suck less.

Re: We Have to Talk About Flask

#46

Post by paulddraper »

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.

Re: We Have to Talk About Flask

#47

Post by rgoulter »

fiddlerwoaroof wrote: post #26
seanc wrote: post #19

Earlier quoted context omitted.

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.

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 while not paying for the effort, seems absurd to me.

Re: We Have to Talk About Flask

#48

Post by paulddraper »

pdonis wrote: post #39
croes wrote: post #28

Earlier quoted context omitted.

>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?

The issue with Flask-Login isn't even a functionality change. Flask just decided to stop making a particular function available in their namespace and now wants you to import it from the Python standard library instead. 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…

> 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.

Forever?

Re: We Have to Talk About Flask

#49

Post by lcnPylGDnU4H9OF »

miguelgrinberg wrote: post #23
mmnfrdmcx wrote: post #6

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.

> 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.

Re: We Have to Talk About Flask

#50

Post by dekhn »

miguelgrinberg wrote: post #27
dekhn wrote: post #5

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!

I agree entirely that maintainers should be more careful with breaking changes. Few things annoy me more than getting 99% of thew way into a project and then getting an error simply because somebody moved a function from one place to the other.

This is really just another instance of CADT, imho.

I can't help with books- and IMHO, this is why books are obsolete for internet technology. I used to be a big OReilly fan, but at some point, the books were worse than useless because none of the examples would work 10 years later. Now, examples don't work 1 year later!

Post reply on HN