# Julia for HEP now available via CVMFS
**URL:** https://discourse.julialang.org/t/julia-for-hep-now-available-via-cvmfs/129737
**Category:** High Energy Physics
**Tags:** hep
**Created:** [June 8, 2025, 11:33am UTC](https://discourse.julialang.org/t/julia-for-hep-now-available-via-cvmfs/129737 "2025-06-08T11:33:28Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@oschulz](https://discourse.julialang.org/u/oschulz)
#### Post date: [June 8, 2025, 11:33am UTC](https://discourse.julialang.org/t/julia-for-hep-now-available-via-cvmfs/129737/1 "2025-06-08T11:33:29Z")
I’m happy to announce that we now have a HEP (particle physics) Julia distribution available via CVMFS (thanks for all the friendly help here!).
Two container images
- [registry.cern.ch/juliahep/juliahep-core:latest](https://github.com/JuliaHEP/juliahep_juliahep-core_img): A lean Alma Linux 9 with Julia v1.11 and v1.12-beta
- [registry.cern.ch/juliahep/juliahep-base:latest](https://github.com/JuliaHEP/juliahep_juliahep-base_img): Builds on juliahep-core and includes a lot of common packages and dependencies via `/opt/julia-VERSION/local/share/julia`. Sets `$JULIA_PKG_PRESERVE_TIERED_INSTALLED=true` so when users add packages, versions already present in the container image will be used as much as possible.
The containers are currently built for x86\_64 only, but we’ll definitely add an ARM version as well.
juliahep-base specifically should make for a nice entry point for users - it doesn’t tell users what packages to use, but packs a large bag of important packages in an internal Julia package depot, ready and precompiled. So when users install packages, a lot of stuff is “already there” and will be re-used. This is important because on many HEP computing systems, users have limited home directory quotas and are on networked file systems that don’t like to deal with very large numbers of files.
The folks that run the unpacked.cern.ch CVMFS repository have kindly agreed to host the containers images (unpacked) on CVMFS (automatically synchronized via [unpacked / sync · GitLab](https://gitlab.cern.ch/unpacked/sync/)). So now we can run `apptainer shell /cvmfs/unpacked.cern.ch/registry.cern.ch/juliahep/juliahep-base\:latest` on any system with Apptainer and CVMFS and Julia is there.
But we don’t even need Apptainer (or another container runtime): One cool thing about Julia is that external dependencies are provided down to basically libc-level. So it’s possible to run the Julia from the unpacked image on CVMFS directly, bare-metal (via a little included wrapper script), on basically any modern Linux with CVMFS:
```julia
$/cvmfs/unpacked.cern.ch/registry.cern.ch/juliahep/juliahep-base\:latest/unpacked/bin/julia
julia> DEPOT_PATH
3-element Vector{String}:
"/home/username/.julia-juliahep-base"
"/cvmfs/unpacked.cern.ch/.flat/b" ⋯ 68 bytes ⋯ "pt/julia-1.11/local/share/julia"
"/cvmfs/unpacked.cern.ch/.flat/b" ⋯ 62 bytes ⋯ "833c/opt/julia-1.11/share/julia"
```
An advantage of running the unpacked image directly, without Apptainer (besides less complexity) is that one doesn’t have to use tricks to run the VSCode-server-component inside of the Apptainer instance, for VSCode to be able to read/show files in the depot included in the container image.
Note: This “bare-metal” way of running Julia from CVMFS is not quite “perfect”, as source-file lookup for packages provided via the container images will point to `/opt/...` instead of `/cvmfs/.../opt/...`. It’s more of an annoyance (when users want to dig through where stuff comes from, etc.), but maybe [something can be done about it](https://github.com/JuliaLang/julia/issues/58671).
---
### Author:  [@misha\_mikhasenko](https://discourse.julialang.org/u/misha_mikhasenko)
#### Post date: [June 8, 2025, 12:49pm UTC](https://discourse.julialang.org/t/julia-for-hep-now-available-via-cvmfs/129737/2 "2025-06-08T12:49:50Z")
Hi @oschulz, thanks for the news and the effort.
More and easier ways to run Julia the better.
What is a difference between,
```julia
/cvmfs/unpacked.cern.ch/registry.cern.ch/juliahep/juliahep-base:latest/unpacked/bin/julia
```
and distributions in
```julia
ls /cvmfs/sft.cern.ch/lcg/releases/julia/
```
?
We need a hep-related blog post “How I set up my julia environment…”
---
### Author:  [@oschulz](https://discourse.julialang.org/u/oschulz)
#### Post date: [June 8, 2025, 3:32pm UTC](https://discourse.julialang.org/t/julia-for-hep-now-available-via-cvmfs/129737/3 "2025-06-08T15:32:34Z")
`/cvmfs/sft.cern.ch/lcg/releases/julia/` are only julia releases for various operating systems. I’m not sure who maintains them, actually, they seems to lag behind, release-wise (still at 1.11.3). They seem to be custom builds, at least some of them, there is a `julia.exe` in `bin` for the Linux releases - though that binary seems to be identical across `x86_64-el9-gcc11-opt`, `x86_64-ubuntu2404-gcc13-opt`, etc.
The new juliahep builds use the offical Julia binaries, and come as full container images. The main point is to have a distribution that prepacks a lot of dependencies, so people can get up and running without a lot of downloading and precompiling on “slow” (for many small files, that is) network file systems.
This is all brand-new, and we still have to figure out how to automatize builds, etc. I put it together for the Julia part of the [Advanced Programming Concepts 2025](https://indico.desy.de/event/48282/) school at DESY last week, in case participants want to work at DESY NAF (20 GB home dir quota), CERN lxplus, etc.
---
### Author:  [@oschulz](https://discourse.julialang.org/u/oschulz)
#### Post date: [June 8, 2025, 5:07pm UTC](https://discourse.julialang.org/t/julia-for-hep-now-available-via-cvmfs/129737/4 "2025-06-08T17:07:51Z")
For example, users on Linux systems with CVMFS any user can now just do
```julia
$ /cvmfs/unpacked.cern.ch/registry.cern.ch/juliahep/juliahep-base\:latest/unpacked/bin/julia
(@v1.11) pkg> activate @hep-base
(@hep-base) pkg>
julia> using CairoMakie
```
Needs some time for CVMFS to cache things, but zero package downloads and zero precompilation. And, when using your own environment instead of the prepacked `hep-base` env:
```julia
$ /cvmfs/unpacked.cern.ch/registry.cern.ch/juliahep/juliahep-base\:latest/unpacked/bin/julia
julia> import Pkg
julia> Pkg.activate(joinpath(first(DEPOT_PATH), "environments", "v$(VERSION.major).$(VERSION.minor)"))
Activating new project at `~/.julia-juliahep-base/environments/v1.11`
(@v1.11) pkg> add CairoMakie
julia> using CairoMakie
```
also zero package installation. Though now it recompiles `CairoMakie`, `FFMPEG_jll`, `LERC_jll`, `Libtiff_jll`, `libwebp_jll`, `Makie` and `WebP` for some reason, even though `$JULIA_CPU_TARGET` is the same as when building the container. Haven’t figured out why yet - for most packages it happily uses the precompilation output stored the container image. For example, for
```julia
$ /cvmfs/unpacked.cern.ch/registry.cern.ch/juliahep/juliahep-base\:latest/unpacked/bin/julia
julia> import Pkg
julia> Pkg.activate(joinpath(first(DEPOT_PATH), "environments", "v$(VERSION.major).$(VERSION.minor)"))
Activating new project at `~/.julia-juliahep-base/environments/v1.11`
(@v1.11) pkg> add Zygote
julia> using Zygote
```
there is zero package installation and zero precompilation, it takes everything from the container image.
No idea what’s different for CairoMakie (compiler experts, can you help?).
---
### Author:  [@jling](https://discourse.julialang.org/u/jling)
#### Post date: [June 8, 2025, 8:48pm UTC](https://discourse.julialang.org/t/julia-for-hep-now-available-via-cvmfs/129737/5 "2025-06-08T20:48:06Z")
> [@oschulz](#):
>
> They seem to be custom builds
it’s not custom. I maintain them more or less (I simply pin them when there’s a new release, I don’t have admin access to LCG storage itself), and we download official Julia binary. the .exe is because we have a script to unset LD\_LIBARAY\_PARH so we need a different name for Julia binary file
> **[Bump Jula to 1.11.4 (!2878) · Merge requests · sft / lcgcmake · GitLab](https://gitlab.cern.ch/sft/lcgcmake/-/merge_requests/2878)**
>
> https://julialang.org/downloads/#current\_stable\_release
---
### Author:  [@oschulz](https://discourse.julialang.org/u/oschulz)
#### Post date: [June 9, 2025, 11:48am UTC](https://discourse.julialang.org/t/julia-for-hep-now-available-via-cvmfs/129737/6 "2025-06-09T11:48:56Z")
Thanks Jerry, good to know! Yes, unsetting `$LD_LIBARAY_PATH` is also what I do in the `/unpacked/bin/julia` wrapper script.