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

81–90 of 116 posts

Re: We Have to Talk About Flask

#81

Post by dekhn »

paulddraper wrote: post #78
dekhn wrote: post #22

Earlier quoted context omitted.

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.

Flask puts a test on someone else's unmaintained pacakge?

In this case, I would expect that the author of this post (who, IIUC is also the creator of flask), should have a test case that trips/fails within a day of the tutorial becoming invalid. At least then he knows the tutorial is going to fail for users.

I was burned by flask/werkzeug enough times to completely avoid flask unless absolutely neccessary.

Re: We Have to Talk About Flask

#82

Post by pdonis »

ilyt wrote: post #65
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…

Adding code into your framework to support abandonware plugins is the exact opposite of better solution

They wouldn't have needed to add any code. They could have just changed their implementation of the function to an import of it from the Python standard library. That would be a net reduction in code size.

Re: We Have to Talk About Flask

#83

Post by pdonis »

paulddraper wrote: post #48
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…

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

For as long as the functionality does not change. Which it didn't when the function was removed; the Python standard library function had the same functionality as the former Flask function that was removed.

Re: We Have to Talk About Flask

#84

Post by pdonis »

tetha wrote: post #51
pdonis wrote: post #35

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. 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 t…

Batching a bunch of breaking changes together so they all come at once and you only have to deal with them once is fine.

What I am asking is, why did there even need to be a breaking change in the case of the function discussed in the article? No functionality changed; the Python standard library function was identical to the former Flask function. So why couldn't the Python standard library function have been imported into the Flask namespace to replace the former Flask function? Why force every user to do that manually?

Re: We Have to Talk About Flask

#85

Post by ilyt »

fiddlerwoaroof wrote: post #72
ilyt wrote: post #63

Earlier quoted context omitted.

Throwing the crust away and refactoring stuff also "doesn't add new features" but it needs to be done to keep codebase good. > giving users no added value to compensate for the time and effort required to deal with the change ... the users of free software. That didn't bother to find&replace one method in their plugin code.

Refactoring is not a breaking change by definition: refactoring is preserving the same contract with a new implementation.

I put "throwing the cruft away" in the same sentence EXPLICITLY to address that I am not just talking about refactoring.

Learn to read before throwing dictionary definitions at people

Providing method now-provided by standard libs is by definition unnecessary cruft. Nobody wants that in their codebase. They warned people for 2 years.

But apparently basic competence is too hard requirement in software ecosystems.

Re: We Have to Talk About Flask

#86

Post by ilyt »

pdonis wrote: post #82
ilyt wrote: post #65

Earlier quoted context omitted.

Adding code into your framework to support abandonware plugins is the exact opposite of better solution

They wouldn't have needed to add any code. They could have just changed their implementation of the function to an import of it from the Python standard library. That would be a net reduction in code size.

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!

Re: We Have to Talk About Flask

#87

Post by kennywinker »

paulddraper wrote: post #77
kennywinker wrote: post #41

Earlier quoted context omitted.

> Blame the tutorial makers and the dependency maintainers I'd blame the python community as a whole, for not driving everybody (flask team, tutorial makers, dependency maintainers, etc) towards pinned versions. This is a well-established problem in any environment where you write code that has dependencies. Strict use of semver, and tools that respect those conventions, would solve MOST of this.

Nothing unique to Python. You can lock Python versions. But people by default, people type pip/npm/apt/yum install without the version. Nothing unique to Python.

Except the default behavior of yarn add / npm install is to pin a semver. I.e. if the current version is 1.2.3, the package.json will specify “^1.2.3” which will auto-update to any new release that’s versioned below 2.0.0. And the node community is at least half-decent about following semver and doesn’t usually push breaking changes on a point-release.

Re: We Have to Talk About Flask

#88

Post by pdonis »

ilyt wrote: post #86
pdonis wrote: post #82

Earlier quoted context omitted.

They wouldn't have needed to add any code. They could have just changed their implementation of the function to an import of it from the Python standard library. That would be a net reduction in code size.

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.

Re: We Have to Talk About Flask

#89

Post by pdonis »

ilyt wrote: post #85
fiddlerwoaroof wrote: post #72

Earlier quoted context omitted.

Refactoring is not a breaking change by definition: refactoring is preserving the same contract with a new implementation.

I put "throwing the cruft away" in the same sentence EXPLICITLY to address that I am not just talking about refactoring. Learn to read before throwing dictionary definitions at people Providing method now-provided by standard libs is by definition unnecessary cruft. Nobody wants that in their codebase. They warned people for 2 years. But apparently basic competence is too hard requirement in software ecosystems.

> Providing method now-provided by standard libs is by definition unnecessary cruft. Nobody wants that in their codebase.

I don't think your sweeping claims here are justified. Importing the function from the standard library into the same namespace in your library where the function you previously implemented was is not "cruft". It's helping your users by not making a breaking change when you don't actually need to--no actual functionality changed.

> apparently basic competence is too hard requirement in software ecosystems

Your snark here is even less justified IMO than your sweeping claims above.

Re: We Have to Talk About Flask

#90

Post by nickjj »

I've been maintaining my Build a SAAS App with Flask video course[0] for 8 years. It has gone from Flask pre-1.0 to 2.3 and has been recorded twice with tons of incremental updates added over the years to keep things current.

In my opinion tutorial creators should pin their versions so that anyone taking the course or going through the tutorial will have a working set up that matches the video or written material.

I'm all for keeping things up to date and do update things every few months but expecting anyone can install any version doesn't tend to work well for tutorials because sometimes bumping a minor version requires a code change or covering new concepts. As a tutorial consumer it's frustrating when the content doesn't match the source code unless it's something simple like a version bump.

As a tutorial creator it's your responsibility to ensure things work which ultimately leads to doing everything in your power to remove time as a variable. You can commit a frozen dependency file which locks everything. I sleep pretty well at night knowing things will work tomorrow. Before I did that I had all sorts of things break over the years due to some dependency of a dependency introducing a backwards incompatible change. Now it's predictable and I can control when it's safe to update a set of packages.

I've held off upgrading Flask to 3.0 and Python 3.12 due to these open issues with popular 3rd party packages https://github.com/nickjj/docker-flask-example/issues/17. I'm sure new releases will get pushed in due time. When they are good to go then I'll add a new video update and all is well for everyone. Maintainers can work at their own pace, I can verify everything works in production and then roll it into the course and folks taking the course get an up to date version that's been proven to work.

[0]: https://buildasaasappwithflask.com/

Post reply on HN