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

111–116 of 116 posts

Re: We Have to Talk About Flask

#111

Post by fiddlerwoaroof »

usrbinbash wrote: post #109
pdonis wrote: post #102

Earlier quoted context omitted.

Yes, for each of the umpteen number of packages that depends on Flask. Instead of Flask just doing it one time and avoiding that breaking change altogether. Open source is supposed to be a community . Forcing a breaking change like this on all their dependencies that they could have avoided with a one-line import statement is, IMO, not very good behavior as a community member.

> Forcing a breaking change No one is forcing a breaking change on anyone. a) PIP usually retains past versions b) A python package can specify it's dependencies, including their version, as hard requirements c) virtualenvs exist If a packages maintainer doesn't want to change his code to support some changes in some_dependency-v4.2, he can specify that the package requires some_dependency-v2.1 or whatever other exis…

This is a pretty naive take that assumes the only relevant parties are the various library authors. The real issue here is the hours and hours of useless maintenance work breaking changes routinely force on anyone writing software with the supposedly "modern" tech stacks. Sure, maybe this change adds a minute of work for someone using flask. How much time does it save flask's maintainers? More than 1 minute * the number of people using flask? Being more hesitant about breaking changes as a industry would eliminate hundreds of person-years of basically useless maintenance work.

Re: We Have to Talk About Flask

#112

Post by usrbinbash »

fiddlerwoaroof wrote: post #111
usrbinbash wrote: post #109

Earlier quoted context omitted.

> Forcing a breaking change No one is forcing a breaking change on anyone. a) PIP usually retains past versions b) A python package can specify it's dependencies, including their version, as hard requirements c) virtualenvs exist If a packages maintainer doesn't want to change his code to support some changes in some_dependency-v4.2, he can specify that the package requires some_dependency-v2.1 or whatever other exis…

This is a pretty naive take that assumes the only relevant parties are the various library authors. The real issue here is the hours and hours of useless maintenance work breaking changes routinely force on anyone writing software with the supposedly "modern" tech stacks. Sure, maybe this change adds a minute of work for someone using flask. How much time does it save flask's maintainers? More than 1 minute * the num…

> Being more hesitant about breaking changes as a industry

... would lead to even more outrage, because we tried that in the past. And the result were "rotting libraries", that became unmaintainable, incomprehensible, and riddled with hard to track and harder to fix bugs, because they had to drag along code that was often more than a decade old, kicking and screaming, just so libadbandonedsincebronzeage.so wouldn't have to issue an update.

So no, we should have breaking changes.

We should keep libraries vital and get rid of old code. We shouldn't drag along stuff just because we can. We have established procedures to deal with this, and with good reason.

Re: We Have to Talk About Flask

#113

Post by usrbinbash »

fiddlerwoaroof wrote: post #110
usrbinbash wrote: post #108

Earlier quoted context omitted.

No. That would break every single module that is compliant with flask 3.x and imports it with `import flask`. This simply isn't justified by the "benefit" of some old packages not having to change a single line of code. Yes, maybe in hindsight it would have been beneficial to put the major version of some packages (flask is far from the only one) directly into the package name, as a workaround for pythons inability t…

As Rich Hickey argues in the talk I referenced, semver and version pinning is a problem not a solution. I’ve written lots of code using only stable dependencies that are stable over the span of decades, and it’s just a much nicer ecosystem to be able to rely on.

> semver and version pinning is a problem not a solution

Almost every practice in software development is a compromise that wouldn't be necessary if some decision in the past were different.

I think I agreed with you somewhere in this thread, that version-names (flask1, flask2, ...) are a better solution than major versions.

However, `flask` as an import name isn't going to go away. That is simply a reality and we have to work with it, because alot of projects rely on this. The same is true for tens of thousands of important software packages all over the OSS landscape.

So we can argue all day and then some over "what if"s...it won't change the status quo that exists, and in that state, semver is a good compromise that solves way more problems than it introduces.

Re: We Have to Talk About Flask

#114

Post by mixmastamyk »

davidhariri wrote: post #97
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?

This is what I'm scratching my head at too. Why would it be a good thing for any OSS maintainer to slow themselves down for packages that don't want to fix deprecation warnings?

- Because that's what you signed up for as maintainer of a project used by millions.

- It's a significant piece of functionality.

- The change is trivial, not worth the cost of losing login.

In some instances Python deprecates something for six years, Flask six months.

Re: We Have to Talk About Flask

#115

Post by mixmastamyk »

ilyt wrote: post #62
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?

I think the author learned for first time of his life that framework plugins need to keep up with framework changes. 2 years (flask 2.0 release) should be plenty for deprecation notice.

Breaking method was only deprecated six months according to the article.

Re: We Have to Talk About Flask

#116

Post by mixmastamyk »

acdha wrote: post #76
nicoz3 wrote: post #74

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…

It’s not missing the point, it’s that the author of this screed lead with whining about a project breaking compatibility on a major release. Since most of the software world has collectively agreed that’s how it’s supposed to work, whatever else they wrote is going to be buried because the author chose to start the post that way. Since they picked a deliberately provocative title there’s little chance that’s going to…

Woosh.
Post reply on HN