Comment by Galanwe
> spent days wrestling with Python dependency hell
I mean I would understand that comment in 2010, but in 2025 it's grossly ridiculous.
> spent days wrestling with Python dependency hell
I mean I would understand that comment in 2010, but in 2025 it's grossly ridiculous.
Well, first, this a purposefully contrived example, that pretty much does not happen in real life scenarios. So you're pretty much acknowledging that there is no real problem by having to resort to such length.
Second, what exactly would you like to happen in that instance? You want to have, in a single project, the same library but at different and conflicting versions. The only way to solve that is to disambiguate, per call site, each use of said library. And guess what, that problem exist and was solved 30 years ago by simply providing different package names for different major version. You want to use both gtk 1 and gtk 2 ? Well you have the "gtk" and "gtk2" package, done, disambiguated. I don't think there is any package manager out there providing "gtk" and having version 1 and 2, it's just "gtk" and "gtk2".
Now we could design a solution around that I guess, nothing is impossible in this brave new world of programing, but that seems like a wasted effort for not-a-problem.
Maybe this doesn’t happen in Python, but I find that hard to believe. This is a common thing in Rust, where cargo does support compiling with multiple versions of the same crate. If I have dependency X that depends on version 1.x of crate Z, and dependency Y which depends on version 2.x, cargo will compile BOTH versions of crate Y, and handle the magic of linking dependencies X and Y to their own, different copies of this common dependency.
Yes, Rust can do this. I know Ruby cannot, and I believe Python may not either, but I am less sure about it because I’m less good with Python’s semantics here, but I’d believe your parent.
I am not even thinking of `uv`, but rather of pyproject.toml, and the various improvements as to how dependencies are declared and resolved. You don't get much simpler than a toml file listing your dependencies and constraints, along with a lock file.
Also let's keep middle school taunts at home.
So in 2025, in Python, if I depend on two packages. A and B, and they both depend on different, API-incompatible or behavior-incompatible (or both) versions of C, that won't be an issue?
That's not my experience and e.g. uv hasn't helped me with that. I believe this is an issue with Python itself?
If parent was saying something "grossly ridiculous" I must be doing something wrong too. And I'm happy to hear what as that would lower the pain of using Python.
I.e. this was assumably true three years ago:
https://stackoverflow.com/questions/70828570/what-if-two-pyt...