Live data from Hacker News

We Have to Talk About Flask

blog.miguelgrinberg.com

51–60 of 116 posts

Re: We Have to Talk About Flask

#51
post #35
post #18

Earlier quoted context omitted.

I'd say the respect towards the users is displayed by the frequency of breaking changes and the overall time to migrate, through deprecation warnings and at least security maintenance of older versions. Sometimes things need to change. Speaking of that, flask 2 was released in May 21. I can't really complain about some breaking changes every 2 years or so. That's almost like a linux distribution.

> I'd say the respect towards the users is displayed by the frequency of breaking changes and the overall time to migrate, through deprecation warnings and at least security maintenance of older versions. Sometimes things need to change. A change that brings new added value to users is a case where the change needs to be made, yes. But the article's point is that the Flask changes don't seem to be doing that. They're…

I disagree with that, to be honest.

At a first glance, you might think "but where is the shiny carrot that makes me upgrade?" But the thing is - we have dealt with major upgrades at work which broke many things, added many features, changed things in undocumented ways, turned the whole dependency inside out.

That's a horrible experience. You end up running after ghosts: Is it the breaking change, is it a change due to a feature, what is even going on!

Looking at it, Flask 3 seems to be a simple batch of several breaking changes on the roadmap for quite some time. This is good - they thought about batching these breaking changes together to have one big bad one, opposed to like 6 of them over the 2 years. And you can upgrade, and you can clearly see if one of the breaking changes causes harm to your application, without having to worry about hundreds of other changes within the same major release.

Re: We Have to Talk About Flask

#52

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.

poetry is very hard to setup

Could you expand on this? I recently started a new project and decided to use poetry for the first time. It didn’t seem difficult at all to me.

Re: We Have to Talk About Flask

#53
post #2

Shouldn't the tutorial author be specifying a version in the tutorial?

Normally tutorials ask readers to install latest versions of everything. If you have to provide a version for every package used in a tutorial, it means that every time any of such dependencies releases a new version the tutorial has to be updated. I guess it is possible for a blog post, but how can I update my books or my videos?

> how can I update my books or my videos?

You shouldn't need to. How/why are you writing tutorials for major versions that don't exist yet?

> `pip install flask` installs the latest version, which is 2.0 at the time of writing

Re: We Have to Talk About Flask

#54

Can anyone challenge the author's assertion that the 3.0 release doesn't bring any improvements?

My assertion is that none of the refactorings in the 3.0 release bring a benefit to the community. I did not imply that the entire 3.0 release is void of improvements.

The nuance escapes me, but I'm sorry to put words in your mouth.

I'm still interested in any countervailing opinions on this particular detail.

Re: We Have to Talk About Flask

#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

Re: We Have to Talk About Flask

#56
Despite the "it's your fault" vibe towards Miguel, I have to say: thank you Miguel!!

Your tutorial was a turning point for me 4 years ago, the care you take to write and help people is very precious. My ability to write modest web apps takes its roots in your free online materials, I am grateful for that.

Re: We Have to Talk About Flask

#57
This is a wider issue with Flask and the surrounding ecosystem, and is also why I switched to Django a couple of years ago. I don't recall which package it was specifically, but there was a commonly used security package that was recommended by lots of blogs and tutorials, but the maintainer no longer wanted to maintain it but also didn't want to let anyone else contribute. So it led to another developer forking it and adding a '2' to the end of the name just to keep it current. This wouldn't have been such a big issue if the package didn't add really important security features to Flask, but due to the minimal nature of Flask it really depends on having a well-managed ecosystem of packages. My takeaway was that I felt I couldn't rely on Flask for an application that required features that weren't in the main Flask package itself.

But just wanted to also say, that the main reason I enjoyed working with Flask at the time, was due to Miguel's excellent mega-tutorial. Again, that speaks to the value of having a good ecosystem to support your solution. Flask have ultimately shot themselves in the foot by releasing something they must have known would break a huge number of sites, without bringing the community along with them on the journey.

Re: We Have to Talk About Flask

#58

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.

Python dependency management certainly has many problems, but I don't think this is one of them--or at least, it's not a problem unique to Python. The practice of tutorials/docs/guides installing unpinned/latest versions is incredibly common in most (all?) scripting languages' communities. While that's not great, I don't think it has anything to do with the fragmentation of Python's dependency management.

Re: We Have to Talk About Flask

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

Re: We Have to Talk About Flask

#60

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.

You don't even need poetry, as great as it is. Write your tutorial to include versions:

> pip install foo==1.2.3

Post reply on HN