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

▲

Galanwe a day ago | parent [-]

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.

▲

virtualritz 6 hours ago | parent | next [-]

> Well, first, this a purposefully contrived example [...]

So you are saying that (a) I made this up and (b) intentionally so.

How so? I am always flabbergasted when people make such statements.

You know nothing of my use of Python. I work in a specific field (computer graphics) and within that an even more specific sub field, visual effects.

I have to use Python maybe every three months. And there is some dependency related pain every single time. Python's dependency management "is straight up terrible" (quoted from elsewhere in this thread), I concur.

And thusly, in my world, this example is not "contrived" and given the aforementioned circumstances -- that were unknown to you -- even less so "purposefully".

> Second, what exactly would you like to happen in that instance?

I would expect Python to namespace-wrap (on-the-fly) conflicting versions.

See Rust for some similar solution.

> [...] a wasted effort for not-a-problem.

If this was "not-a-problem" why would Rust/cargo go out of its way to solve it? And why would people regularly point out for this to be one of the reasons dependencies are indeed a "not-a-problem" in Rust and how great that is compared to whatever else they battled with before?

Indeed you and I do live in different worlds.

▲

adastra22 a day ago | parent | prev [-]

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.

	▲	steveklabnik 21 hours ago \| parent [-]
		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.