Multiple versions of same dependency

[bakaq]

How should we deal with a dependency tree that has 2 versions of the same dependency? Ideally we could have both dependencies in the tree (Rust's Cargo does that), but I don't think it would be possible with Scryer's module system, so we probably should go with just having 1 version of each package in the resolved tree (kinda like Python).

Does anyone have any ideas about this?

[constraintAutomaton]

I'm not sure how Python handles this, but how does it work with a lockfile? If a transitive dependency uses a different version of a package, how do we make sure the behavior stays the same?

[constraintAutomaton]

At least personally, I should do a "literature review" of modern package managers.

[bakaq]

I'm not sure how Python handles this [...]

Python (by this I mean pip) just, like, doesn't. It tries to find 1 version that makes everyone happy, and puts it in a flat directory of packages similar to what we are currently doing in scryer_libs. The way Python gets around this is by having different environments (pyenv, venv and friends), so that each environment can have a different package version, but as far as I know inside each environment there can still only be 1 version of a package.

If a transitive dependency uses a different version of a package, how do we make sure the behavior stays the same?

That's why dependency resolution (and things to work with it, like semantic versioning) exists. If a package declares that it needs ">=1.2.3,<2" and one of it's dependencies declares ">=1.4.7,<2", then we could pick the single version "1.4.7" that would make both happy. Prolog with library(clpz) is perfect to solve this kind of problem, and in fact most package managers implement a mini-prolog to do exactly this.

The limitation with Python (and what I'm talking about here) is that if there is no way to get a single version so satisfy the requirements (like if one package wants ">=1,<2" and another ">=2,<3"), it just gives up and you can't run your code. Rust (Cargo), on the other hand, can have multiple versions of the same package (in this case it would have both version 1 and 2 of the dependency coexisting), but this is because it has a lot of control during linking so that it can ensure both work properly. Python and Prolog with Quintus-style module system doesn't have this control, there will be inevitable module collisions, and that's why I believe the only way forward is to do it Python style and just give up.

This is something that people may want to keep in mind while developing new module systems for Prolog in the future. For example, I just looked and it seems that while Javascript (npm) has this same problem, it can circumvent it with package aliases (which is possible in Javascript's module system).