Pkg.jl: Can two Project.toml files work together seamlessly?

[einzigsue]

If so, how it is supposed to? Can they work seamlessly in the following case?

For example, I have two environments. One is constant with only read permission, but the other environment B is writable. Say module M and N have been installed in the read-only environment A with its own Project.toml and Manifest.toml in $A/environments/v1.1/ and the module P, which depends on M and N, exists in the environment B with its own Project.toml and Manifest.toml in $B/environments/v1.1/ and they look like the following.

`$ cat Project.toml

[deps]
DataFramesMeta = "1313f7d8-7da2-5740-9ea0-a2ca25f37964"
`

and

`
$cat Manifest
....
[[M]]
deps = ["Serialization"]
uuid = "a93c6f00-e57d-5684-b7b6-d8193f3e46c0"

[[N]]
deps = ["SHA"]
uuid = "189a3867-3050-52da-a836-e630ba90ab69"

[[P]]
deps = ["M", "N"]
git-tree-sha1 = "853109fcd1ac1a31c4fb757401a25f260e827aa1"
uuid = "1313f7d8-7da2-5740-9ea0-a2ca25f37964"
version = "0.4.1"
`

How B is supposed to work with A so that when doing using M it knows to read from $A/packages/M and write to $B/compiled/v1.1 and when doing add Q it knows to lookup the dependencies in both $A and $B and write only those ones do not exist in both $A and $B to $B/packages and updates only the Project.toml and Manifest.toml in $B/environments/v1.1/?

I am currently setting JULIA_DEPOT_PATH as $B:$A and LOAD_PATH as default [@:@v#.#:@stdlib]. It does allow writing M.ji to $B/compiled/v1.1 while reading from $A/packages/ when doing using M in julia as long as $B/environments/v1.1/Project.toml doesn't exist. It also allows installing P into $B/packages/ after I touched a Project.toml inside the folder $B/environments/v1.1/. However, as soon as it realised there are two Project.toml files. it seems to stop looking into $A/environment/v1.1 any more. When there is no $B/environments/v1.1 it continues to look into $A/environments/v1.1 but once $B/environments/v1.1 exists, the next place to look into is $A/../stdlib/v1.1 (I am actually not 100% sure how this one is interpreted). Is it related to how the load path is expanded as in base/initdefs.jl line 149?

Yue

[StefanKarpinski]

You seem to be trying to use depots to accomplish what the load path is for. The A and B that you’re referring to as “environments” are actually depots not environments. The things called v1.1 inside of the environments directories in those depots are (appropriately enough) environments. If you have v1.1 in two different depots you’re only ever going to find the one that’s in the depot earlier in the depot path, so the first thing to do is to give them different names. Then they can love in the same depot or different ones. Have both names in the LOAD_PATH and they will become “stacked” with the one that’s earlier in the load path taking precedence. So you probably want the B environment earlier in the load path than A.

[rfourquet]

Then they can love in the same depot

:heart:

[StefanKarpinski]

Now that I'm at a computer instead of on a phone, I can be a little more specific. You're trying to stack these:

• $A/environments/v1.1
• $B/environments/v1.1

That's not possible because the mechanism for stacking environments is the LOAD_PATH and the way you would refer to these environments is by name and they both have the same name—v1.1. So what you'd want to do instead is something like this:

• ~/.julia/environments/A
• ~/.julia/environments/B

and then have LOAD_PATH == ["@B", "@A", "@stdlib"]. They can also be in different depots but they don't have to be. They do need different names.

[einzigsue]

Many thanks:)