Hacker News new | ask | show | jobs
by usrbinbash 975 days ago
> 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.

1 comments

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

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

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

Exactly.