Use of defaultStdlib in Package.juvix breaks compilation when Juvix version is updated

[paulcadman]

You can specify defaultStdlib in the Package.juvix to use the stdlib that's bundled with the compiler:

module Package;

import PackageDescription.V2 open;

package : Package :=
  defaultPackage@{
    name := "anoma-applib";
    version := mkVersion 0 6 0;
    dependencies := [defaultStdlib];
  };

However this is resolved to a path in the juvix.lock.yaml that includes the Juvix version:

version: 2
checksum: e9d510f29d070badc15f3b0009e471b4c9f433d8bc0f82324c011d00b5d21d11
dependencies:
- path: .juvix-build/0.6.9/stdlib/
  dependencies: []

So when the juvix compiler version changes, this path may not exist (especially for dependent packages), and the compilation will break until the lock file is updated using juvix dependencies update.

This bug was introduced in:

• Include the juvix version in the build directory path #3069

[lukaszcz]

On a related note, if you don't specify defaultStdlib but a concrete version number instead, things are likely to break if a dependency package uses a different stdlib version and uses stdlib types in its interface. We get this, e.g., with juvix-test in stdlib tests. After updating stdlib, the juvix-test package uses a different version of stdlib and we get the error:

juvix-stdlib/test/Test/Queue.juvix:25:7-18: error:
No trait instance found for: Eq (Queue Nat)

The reason is that Eq refers to the Eq from the stdlib dependency of juvix-test, but Queue and Nat refer to types from our new modified standard library. After #3069 the two versions of stdlib are separate.

[janmasrovira]

The issues about No trait instance for: Monad M that I showed this morning was exactly the problem mentioned by @lukaszcz.