4 ms·

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

by pdonis 3y ago

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 is no longer actively maintained. Also, as the article notes, Flask-Login is by no means the only Flask-using Python package that was broken by this change. Are all of those other packages no longer actively maintained? I doubt it.

paulddraper 3y ago
> 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?
- pdonis 3y ago
  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.
ilyt 3y ago
Adding code into your framework to support abandonware plugins is the exact opposite of better solution
- pdonis 3y ago
  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.
  - ilyt 3y ago
    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!
    - pdonis 3y ago
      > 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.
      - ilyt 3y ago
        Right, then commit that one line fix to the plugin
        pdonis 3y ago
        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.
        usrbinbash 3y ago
        > 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.
usrbinbash 3y 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.
- pdonis 3y ago
  > 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.
  - fiddlerwoaroof 3y ago
    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
    - pdonis 3y ago
      > There’s also no onus on me to continue using packages that force me to spend valuable time fixing their breaking changes. Exactly.
  - usrbinbash 3y ago
    > 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?

by pdonis 3y ago

paulddraper 3y ago

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

pdonis 3y ago
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.

ilyt 3y ago

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

pdonis 3y ago
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.
- ilyt 3y ago
  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!
  - pdonis 3y ago
    > 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.
    - ilyt 3y ago
      Right, then commit that one line fix to the plugin
      - pdonis 3y ago
        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.
        usrbinbash 3y ago
        > 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.

usrbinbash 3y 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.

pdonis 3y ago
> 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.
- fiddlerwoaroof 3y ago
  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
  - pdonis 3y ago
    > There’s also no onus on me to continue using packages that force me to spend valuable time fixing their breaking changes. Exactly.
- usrbinbash 3y ago
  > 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?