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

101–110 of 116 posts

Re: We Have to Talk About Flask

#101

Post by pdonis »

usrbinbash wrote: post #99
pdonis wrote: post #39

Earlier quoted context omitted.

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…

> Flask-Login is by no means the only Flask-using Python package that was broken by this change Package maintenance also means to keep up with changes in the packages dependencies. If I don't do that, that's my problem, not the dependencies. If I want to fix a certain version as my requirement, I can do so. Every major package system, including the ones used in Python, allow this. If I don't want that, then I need to…

> There is no onus on the dependencies maintainers to care about whether I do my maintenance or not.

There's no "onus" on Flask to do anything they don't want to do. But if Flask forces every package that depends on them to fix a breaking change that they could have avoided with a one-line import statement, I would argue that is not very respectful of all those other package maintainers.

Re: We Have to Talk About Flask

#102

Post by pdonis »

ilyt wrote: post #94
pdonis wrote: post #88

Earlier quoted context omitted.

> Or remove it altogether Which, as the GP of my original post in this subthread argued, and I agree, is not respectful to your users. Importing the function from the Python standard library is a one-liner, hardly an arduous burden.

Right, then commit that one line fix to the plugin

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.

Re: We Have to Talk About Flask

#103

Post by fiddlerwoaroof »

pdonis wrote: post #101
usrbinbash wrote: post #99

Earlier quoted context omitted.

> Flask-Login is by no means the only Flask-using Python package that was broken by this change Package maintenance also means to keep up with changes in the packages dependencies. If I don't do that, that's my problem, not the dependencies. If I want to fix a certain version as my requirement, I can do so. Every major package system, including the ones used in Python, allow this. If I don't want that, then I need to…

> There is no onus on the dependencies maintainers to care about whether I do my maintenance or not. There's no "onus" on Flask to do anything they don't want to do. But if Flask forces every package that depends on them to fix a breaking change that they could have avoided with a one-line import statement, I would argue that is not very respectful of all those other package maintainers.

There’s also no onus on me to continue using packages that force me to spend valuable time fixing their breaking changes. My rule of thumb for dependencies is that, once I have to fix three or four breaking changes, the cost of switching to a more stable alternative or writing my own becomes more worth it.

There’s also the option of releasing a package called something like flask2_compatibility that monkeypatches flask3 to work with flask2

Re: We Have to Talk About Flask

#104

Post by pdonis »

fiddlerwoaroof wrote: post #103
pdonis wrote: post #101

Earlier quoted context omitted.

> There is no onus on the dependencies maintainers to care about whether I do my maintenance or not. There's no "onus" on Flask to do anything they don't want to do. But if Flask forces every package that depends on them to fix a breaking change that they could have avoided with a one-line import statement, I would argue that is not very respectful of all those other package maintainers.

There’s also no onus on me to continue using packages that force me to spend valuable time fixing their breaking changes. My rule of thumb for dependencies is that, once I have to fix three or four breaking changes, the cost of switching to a more stable alternative or writing my own becomes more worth it. There’s also the option of releasing a package called something like flask2_compatibility that monkeypatches fla…

> There’s also no onus on me to continue using packages that force me to spend valuable time fixing their breaking changes.

Exactly.

Re: We Have to Talk About Flask

#105

Post by usrbinbash »

pdonis wrote: post #101
usrbinbash wrote: post #99

Earlier quoted context omitted.

> Flask-Login is by no means the only Flask-using Python package that was broken by this change Package maintenance also means to keep up with changes in the packages dependencies. If I don't do that, that's my problem, not the dependencies. If I want to fix a certain version as my requirement, I can do so. Every major package system, including the ones used in Python, allow this. If I don't want that, then I need to…

> There is no onus on the dependencies maintainers to care about whether I do my maintenance or not. There's no "onus" on Flask to do anything they don't want to do. But if Flask forces every package that depends on them to fix a breaking change that they could have avoided with a one-line import statement, I would argue that is not very respectful of all those other package maintainers.

> But if Flask forces every package

The reverse would be that every package that depends on flask forces it to make all future changes dependent on whether or not they break someones code. Which obviously isn't a sustainable model for software development.

> I would argue that is not very respectful of all those other package maintainers.

Define what is "respectful" then?

The flask team announces changes. They deprecate things. They use deprecation warnings. They use major versions correctly. They honor well established good practices in software development, to give package maintainers the opportunity to react to changes early.

Please, do explain: What else is required to meet whatever definition of "respectful" we are talking about here?

Re: We Have to Talk About Flask

#106

Post by usrbinbash »

fiddlerwoaroof wrote: post #29
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?

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

The version number, and especially the major version, IS part of the name, so they did exactly that.

Re: We Have to Talk About Flask

#107

Post by fiddlerwoaroof »

usrbinbash wrote: post #106
fiddlerwoaroof wrote: post #29

Earlier quoted context omitted.

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

The version number, and especially the major version, IS part of the name, so they did exactly that.

Then require people to `import flask3` so you can install both major versions together.

Re: We Have to Talk About Flask

#108

Post by usrbinbash »

fiddlerwoaroof wrote: post #107
usrbinbash wrote: post #106

Earlier quoted context omitted.

The version number, and especially the major version, IS part of the name, so they did exactly that.

Then require people to `import flask3` so you can install both major versions together.

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 to deal with multiple versions of the same module under the same name in one environment. But python works as it does, `import flask` is how god-knows how many projects use it, so that's how the show runs, period.

If some package requires a certain version, it can pin that version in its `setup.py`. If a project requires a certain version it can pin that version in it's `requirements.txt`. If an environment requires a certain version, the admin can create a virtualenv.

Re: We Have to Talk About Flask

#109

Post by usrbinbash »

pdonis wrote: post #102
ilyt wrote: post #94

Earlier quoted context omitted.

Right, then commit that one line fix to the plugin

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 existing version he is happy with.

If he doesn't do that, and instead specifies only `some_dependency`, that signals to the package management software that the package works with the `@latest` version of that dependency. The onus to make sure that is, and continues to be, the case in code, is on the maintainer of the package, not the maintainer of the dependency, period.

And no, this is not "disrespectful". This doesn't go against any sense of community in FOSS. This is established practice in software development and package maintenance.

Re: We Have to Talk About Flask

#110

Post by fiddlerwoaroof »

usrbinbash wrote: post #108
fiddlerwoaroof wrote: post #107

Earlier quoted context omitted.

Then require people to `import flask3` so you can install both major versions together.

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.
Post reply on HN