Resolve conflicting packages

[ZenVoich]

I'm wondering how we could resolve two version of the same package with a breaking changes?

For example:

1. Package A v1.0.0 with method foo
2. Package A v2.0.0 w/o method foo but with new method bar
3. Package B v1.0.0 depends on package A v1.0.0 and using method foo
4. User who needs package B and method bar from package A v2.0.0

As an option, we could resolve package folder for a specific folder: Example for moc:

--package B .mops/[email protected]
--package A .mops/[email protected]
--package A .mops/[email protected] .mops/[email protected]

Here, the last line specifies to resolve package A to folder .mops/[email protected], but only for source files located in .mops/[email protected]. For any other source files, resolve package A to folder .mops/[email protected]

[rvanasa]

I'll bring this up with the Languages team to see if we could build something like this into the compiler.

[ZenVoich]

@rvanasa thank you

[crusso]

Arguably, the author of package A should have just deprecated foo instead of removing it completely, but perhaps I'm being too naive here.

I think in the particular scenario above, the user could just resolve the issue by importing the new version of A under a different package name, but that probably doesn't solve the general situation you want to address.

I'm not sure there is a good solution to this problem. In some case, you'll want packages to agree an the implementation of common imports, because they need to communicate values between them, but in other cases you might want each to have their own independent copy of the package, because they don't actually expose the dependency and don't need to agree.

One solution might be to a have more expressive module system, with OCaml/SML style functors (parameterised modules). Then you could express that B is parameterised by package A, and instantiate B to a particular choice of A while also importing a different implementation of A for the rest of the code.

[ZenVoich]

One solution might be to a have more expressive module system, with OCaml/SML style functors (parameterised modules). Then you could express that B is parameterised by package A, and instantiate B to a particular choice of A while also importing a different implementation of A for the rest of the code.

Is it possible to implement this in moc without having to change/manage the source code of the packages? Maybe the way I suggested in the first post?

If moc had such a feature, and if we make an agreement that all packages must follow semver, the package manager could resolve such conflicts automatically based on major versions.

For example, if there are two major versions of pkg 1.0.0 and 2.0.0(supposing with breaking changes), mops could resolve both of them. If there are a lot of minor versions of pkg(1.0.0, 1.6.3, 1.6.6, 1.9.9), mops could resolve to latest one - 1.9.9, because there should be no breaking changes and it will include new features that other packages probably need