What is the expectation when major version clashes occur between a library and your code?

[brettcannon]

https://docs.inko-lang.org/manual/main/getting-started/modules/#version-selection says:

If packages require different major versions of another package, Inko produces an error as we don't support using multiple major versions of the same package.

The way I read that is that Inko is setting an implicit upper bound constraint of the major version. I'm curious as to how you expect folks to handle clashes due to this (e.g., a library I use wants json >= 1.8.5, but I want to use json >= 2.0.0 directly)? In the Python community where we also have a flat namespace for libraries, and thus only a single version of anything for a program, we have found upper bounds as something to be avoided. Coming from the community and viewpoint, I'm trying to understand how Inko suggests people handle this situation?

[yorickpeterse]

Inko's approach to including dependencies is to basically dump all of them in ./dep/src, then add that to the compiler's import paths. This means we can't support multiple versions of the same package, as their namespaces/files would conflict. Go handles this by treating different major versions as different packages, but then you end up with the mess of having to include these major versions in your imports (e.g. import foo::v1 and import foo::v2).

Other than maintainers having to be careful about bumping major versions and coordinating this with depending libraries, I haven't really figured out yet what would work well given the above constraints 😕

[brettcannon]

It's definitely tricky. Having transitive dependencies always makes this complicated when it comes to some breaking change that someone wants while someone else doesn't. And in a typed language it's even harder.

[yorickpeterse]

Indeed. I suspect we'll go with the "major version is a new package approach" at some point, as it's the only decent solution I can think of. Unlike Go, I think it wouldn't be too bad, because:

• It would be more consistent, in that you'd have to do import foo::v0 for major version 0 and import foo::v1 for major version 1, whereas Go IIRC allows the equivalent of import foo for major version 0 and 1
• Within your package's repository you don't have to care about the version, i.e. the source code is still in src/foo/ and not src/foo/v1; instead the package manager just dumps the files in ./dep/src/foo/v1. This also makes writing your tests easier, as you don't need to change a whole bunch of imports every time you bump your package's major version
• No need for messing with tags and what not

[yorickpeterse]

I created #593 to track adding support for different mayor versions.

[yorickpeterse]

0.13.1 was just released, which includes support for multiple major versions of the same package. Some extra details are found here.