Make Julia environments separation based on full version number

I would like to make Julia installations that create different environments based on the full Julia version number. That is instead of e.g.


I would like to have e.g.:


Does anybody know how to achieve that?

Motivation: the aim is to enable full reproducibility of a certain state of a Julia application.

$ export JULIA_LOAD_PATH="@:@v#.#.#:@stdlib"

Perfect, that works! thanks @fredrikekre! Just a short question for confirmation please: do I understand right that the environments that will be created that way (e.g. v1.0.1, v1.0.4, v1.1.0, v1.1.1) will be completely independent and not share anything? In particular, they will not share any package even if I install the same package e.g. for v1.0.1 and for v1.0.4?

UPDATE: it turns out that this is not a complete solution as e.g. precompiled modules are not stored based on the full version number, see below…


In the Pkg documentation it says: “Pkg is designed around ‘environments’: independent sets of packages that can be local to an individual project or shared and selected by name” [1]. I understand this as follows (and quick tests seem to confirm that). If I install a same version of a package in two different environments, e.g. v1.1 and v2.0 (in the future…), then this package installation will not be duplicated: the package will be just installed once in ~/.julia/packages, but added to both environments’ Project.toml. How can we be sure that Julia v1.1 and v2.0 will build this package the same way? Is it really safe to build it only once and share it?

@fredrikekre: concerning the solution that you gave: the precompile path is not changed accordingly, that is, I get e.g.


but then the precompiled modules are still in


Do you know how we can also change the path where the precompiled modules are stored?

The current best way to do this is to change DEPOT_PATH

You mean to use a different DEPOT_PATH for each version? But, then I would get a redundant version number in environments, e.g.:


This would not really be an issue besides aesthetics.

I’m curious why you want to do this. It sounds to me like you might be better off using projects explicitly instead of using the default environments.

You are certainly right that it is best to use explicit separate environments per project. However, I am preparing an installation on our supercomputer and we need to make sure that the default configuration is as good as possible. So we need to prevent as much as possible foreseeable problems that may occur when the user does not use explicit separate environments per project. Moreover, we need to have a maximal reproducibility of user problems in case they need help…

1 Like

Ahh, got it. That makes sense.

Does anyone know how to change the path were the precompiled modules are stored?