So I use julia v1.10. I for example, open up julia session and then activate shared environment like so:
(@geo) pkg> activate --shared ml3d
Activating project at `~/.julia/environments/ml3d`
(@ml3d) pkg> st
Status `~/.julia/environments/ml3d/Project.toml`
⌅ [052768ef] CUDA v5.7.3
⌃ [587475ba] Flux v0.16.3
[991e6b22] GaussianSplatting v1.0.1 `https://github.com/JuliaNeuralGraphics/GaussianSplatting.jl.git#main`
⌃ [02a925ec] cuDNN v1.4.2
Info Packages marked with ⌃ and ⌅ have new versions available. Those with ⌃ may be upgradable, but those with ⌅ are restricted by compatibility constraints from upgrading. To see why use `status --outdated`
And then when I use the CUDA package, it must be precompiled.
julia> using CUDA
[ Info: Precompiling CUDA [052768ef-5323-5732-b1bb-66c8b64840ba]
Precompiling AtomixCUDAExt finished.
1 dependency successfully precompiled in 47 seconds. 72 already precompiled.
[ Info: Precompiling AtomixCUDAExt [13011619-4c7c-5ef0-948f-5fc81565cd05]
┌ Warning: Module CUDA with build ID fafbfcfd-ce1c-4354-0000-078a6d9ddb67 is missing from the cache.
│ This may mean CUDA [052768ef-5323-5732-b1bb-66c8b64840ba] does not support precompilation but is imported by a module that does.
└ @ Base loading.jl:2018
[ Info: Skipping precompilation since __precompile__(false). Importing AtomixCUDAExt [13011619-4c7c-5ef0-948f-5fc81565cd05].
This happens to every other environment that is not the main v1.10 environment.
(@v1.10) pkg> activate --shared geo
Activating project at `~/.julia/environments/geo`
julia> using Geo
GeoIO
GeoStats
julia> using GeoStats
[ Info: Precompiling GeoStats [dcc97b0b-8ce5-5539-9008-bb190f959ef6]
Is this some kind of bug? I remember before I upgraded to v1.11, I had perfectly good environments set up. I later downgraded to v1.10 but still packages need precompilation on every turn of environment. (I kinda saw somewhere that it’s v1.11 issue such that you need to start julia with julia --project ?
Edit: Turns out julia --project works.
julia --project=~/.julia/environments/ml3d
_
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.10.9 (2025-03-10)
_/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |
julia> using CUDA
Hard to say if there’s anything strange going on because it’s not clear what conditions this is happening in. I don’t use custom shared environments, so I tried to make one for Julia v1.10 real quick, though installing GeoStats wasn’t quick at all.
After that, I could activate it from the REPL in new processes then import `GeoStats` without precompilation kicking in.
PS C:\Users\Benny> julia +1.10
_
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.10.9 (2025-03-10)
_/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |
(@v1.10) pkg> activate --shared blah11
Activating project at `C:\Users\Benny\.julia\environments\blah11`
julia> using GeoStats
julia>
So that GeoStats precompilation might not be fine. The __precompile__(false) for AtomixCUDAExt definitely doesn’t seem fine, but I don’t use Atomix so I don’t know.
Still, depending on what you were doing, some of the precompilation could have been reasonably triggered. A precompiled package doesn’t depend only on the package and its particular version. It also depends on the Julia version (which determines the compiler itself), the compatible versions of every other package in a given environment, and in bad cases the package versions irreversibly loaded into a process prior to activating an environment with contradicting versions. If any of those change, we need some (often not all) different precompiled packages, and only 10 per package are stored in the precompiled cache by default (JULIA_MAX_NUM_PRECOMPILE_FILES). Worst case if I’m cycling through >10 different environments with different versions of a package, I’m triggering its precompilation every process.
Does this still happen with julia --startup-file=no? If that fixes it, it implies there’s a package that’s loaded during startup with a version that’s incompatible with something in the ml3d environment.
in your default environment and a dependency of your project environment
loaded by your startup.jl (since you’re using Revise, the “culprit” is most likely OrderedCollections.jl)
resolved to different versions in your default Manifest.toml and your project’s Manifest.toml
You may have precompiled your project and its dependencies using the project’s Manifest.toml, but then when you start a new session without julia --project, you load the culprit with the version resolved in the default environment. Thus all project code that depends on that package needs to be recompiled.
julia --project ensures that all package versions are taken from the project, even those loaded by your startup.jl. Thus there is no version conflict and you can use the code you previously precompiled.