We Have to Talk About Flask • Hacker News Board

Re: We Have to Talk About Flask

#21

Post by sdenton4 » Thu, Oct 19, 2023, 5:07 PM UTC

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.

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.

Re: We Have to Talk About Flask

#22

Post by dekhn » Thu, Oct 19, 2023, 5:07 PM UTC

JoeAltmaier wrote: post #4

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.

Re: We Have to Talk About Flask

#23

Post by miguelgrinberg » Thu, Oct 19, 2023, 5:08 PM UTC

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.

Re: We Have to Talk About Flask

#24

Post by Forgotthepass8 » Thu, Oct 19, 2023, 5:08 PM UTC

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.

Re: We Have to Talk About Flask

#25

Post by skrebbel » Thu, Oct 19, 2023, 5:09 PM UTC

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.

Re: We Have to Talk About Flask

#26

Post by fiddlerwoaroof » Thu, Oct 19, 2023, 5:09 PM UTC

seanc wrote: post #19

bckr wrote: post #17

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.

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.

Re: We Have to Talk About Flask

#27

Post by miguelgrinberg » Thu, Oct 19, 2023, 5:09 PM UTC

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!

Re: We Have to Talk About Flask

#28

Post by croes » Thu, Oct 19, 2023, 5:09 PM UTC

fiddlerwoaroof wrote: post #13

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

Re: We Have to Talk About Flask

#29

Post by fiddlerwoaroof » Thu, Oct 19, 2023, 5:10 PM UTC

croes wrote: post #28

fiddlerwoaroof wrote: post #13

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?

Breaking changes shouldn’t happen with the same name: if you want to break your users, pick a new name too

Re: We Have to Talk About Flask

#30

Post by vharuck » Thu, Oct 19, 2023, 5:10 PM UTC

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.