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

91–100 of 116 posts

Re: We Have to Talk About Flask

#91

Post by usrbinbash »

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.

> an API change is a very big deal, to be used only when the older version just can't work anymore

That's one opinion.

Another opinion is, that API and major version changes can be used whenever the maintainers of an open source project feel like it. No other reason is necessary. Because it's their project. They write the code. They don't have to justify that decision.

If a large portion of the projects userbase is unhappy about that, the project will lose traction and new project, or a fork, will arise.

Re: We Have to Talk About Flask

#92

Post by toolslive »

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?

in the context of python, what exactly is an api change? If my api is

   ```
      def some_function(*args, **kwargs) -> JSON:
         ...
   ```
In essence, I'm pretty sure plenty of the changes in the set of parameters that are actually acceptable quite often changes accidentally (same for what's in the JSON)

Re: We Have to Talk About Flask

#93

Post by Saphyel »

amanzi wrote: post #59
Saphyel wrote: post #55

So this is yet another post about how terrible is the python ecosystem with the versions. The author of the post seems unfamiliar with the meaning of a major release. maxcountryman (author of flask-login) doesn't know how to pin down versions. I'm not a big fan of Flask to be honest but this doesn't seem a problem from them. I'd rather blame maxcountryman , the author of the post or pip for this case

Flask is a minimal web framework that relies on its ecosystem of packages and tutorials to keep it current and relevant. So yes, this is a problem for Flask if key packages that are recommended in just about all tutorials do not keep up to date.

Technically wrong. Parallels only develops Flask and they want to keep Flask as minimal as possible, they don't even want to move away from the legacy optparse for Click, so this kind of "minimal work".

Key packages are developed by the community so lack of understanding or no cooperation with Parallels it's not really a Flask issue.

Unfortunately the only solutions for this are:

* Join Parallels and try to change things.

* Use different package, there's plenty web frameworks.

* Understand better semver, and python should try to promote this, or move away from semver to calendar releases like Ubuntu/Jetbrains

Re: We Have to Talk About Flask

#94

Post by ilyt »

pdonis wrote: post #88
ilyt wrote: post #86

Earlier quoted context omitted.

Or remove it altogether, warn people for years about deprecation, then remove all of them. Which they did. More net lines removed too. But hey, it annoyed Man That Is Bad At Dependency Management and Wrote A Book About It so it must be bad!

> 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

Re: We Have to Talk About Flask

#96

Post by regularfry »

It seems to me that the problem here is that everyone directly depends on pypi. The Debian model would be to introduce another repository layer, explicitly to say "everything you install from this repository will work together". Hoping to achieve the same effect with version numbers is a fool's errand, especially when nobody agrees what version numbers mean.

Re: We Have to Talk About Flask

#97

Post by davidhariri »

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?

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?

Re: We Have to Talk About Flask

#98

Post by usrbinbash »

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

> breaking changes in widely-used packages are disrespectful to your users

No they are not.

The flask team announces changes, deprecates things and uses major versions correctly. The major version change also doesn't happen frequently.

If a package absolutely requires a certain version, IT CAN SPECIFY AS MUCH in its requirements. If it doesn't, tough luck.

Re: We Have to Talk About Flask

#99

Post by usrbinbash »

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…

> 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 keep my package maintained, and that means keeping an eye on what my dependencies do. That's part of package maintenance, simple as that.

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

Re: We Have to Talk About Flask

#100

Post by usrbinbash »

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.

> A numbering scheme doesn’t really make it suck any less.

Yes it does, because that "numbering scheme" tells my users when and if breaking changes happen.

It also allows them to avoid them. Don't want to keep up with the dependency? Make the version a hard requirement. Done.

Post reply on HN