Shared environments

I recently learned about “shared environments”, aka the default v1.3 environment. It’s quite a revelation, but I don’t understand how it works. Suppose I have

  • Package A which depends on B@v1.0.0, and is compatible with no other version of B. A is in the shared environment’s Project.toml.
  • Environment E, which has package C in its Project.toml. C depends on B@v2.0.0 (compatible with no other version).

When I am in E and I using A, which version of B is loaded?

I think you will find this useful:

Compat has nothing to do with what is being loaded. Compat is used by the resolver when the Manifest is created but nothing in the code that loads packages looks at it.

Given a package to be loaded, each Manifest in Base.load_path() is looked at and the version that is first found is loaded. So here, you want to load B and B exists in the manifest file of project E so whatever version is in there will be loaded.

2 Likes

E requires C, which is only compatible with B@v2.0.0, so that would be loaded? Then how can using A succeed, if it’s only compatible with B@v1.0.0?

In other words, I always assumed that you can’t combine/stack environments, because the manifest of environment 1 and environment 2 can be incompatible. You’d have to resolve the combined Project.toml together, which doesn’t seem to be done?

Or are two different versions of A loaded simultaneously?

It might fail.

No, only one version of each package is ever loaded in a Julia session.

3 Likes

Ok, so if A is currently at v1.3.0 in the shared environment (unpinned), incompatible with the B version in the E manifest, does using A fail right away, or does julia look for another version of A compatible with the B from E?

With fail I just meant that package A might not work correctly because an incompatible version of B is loaded.

Again, compat information does not influence what package is being loaded at all.

2 Likes

Oh, makes sense! Sorry for being obtuse above, and thank you for the patient answers.

1 Like