3 ms·
> I've never had a JVM dependency break because I upgraded Maven. I have had that exact issue with Python - we're using Apache Airflow, and anyone who installed
by m45t3r 7y ago
> I've never had a JVM dependency break because I upgraded Maven. I have had that exact issue with Python - we're using Apache Airflow, and anyone who installed the latest version of Pip hit an issue - Pip had changed an API that Python dependencies depended on, so Airflow could no longer be installed by that version of Pip, because it was written for the old API. Have fun googling "TypeError: 'module' object is not callable" to enjoy that rabbit hole.
Pip explicitly has no API (except for its command line interface), even the Pip namespace implicates this (pip._internal). So if some dependency is using a Pip "API" they're wrong.
Now, I am developing an application that needs to interface with Pip, in this case it may be appropriate to use the internal Pip API if you pin your Pip version in requirements.txt. However a library shouldn't do this ever.
- EdwardDiego 7y agoSure, it's wrong, not going to disagree. But it happened with a "plain ol requirements.txt", hence why I don't rate Python dependency management as highly as you do.
- m45t3r 7y agoWhat do you mean "plain ol requirements.txt" in this case? Either you're pinning your dependencies in requirements.txt (in this case, you wouldn't have a problem since requirements.txt is acting like a lockfile) or you're doing it wrong. I mean, there is no problem to depend in a internal API if you're locking the versions, if not, just assume the consequences. BTW, I don't rate Python dependency management very high: most other languages have better solutions. However it is manageable.