Right now precompilation is run on users’ computers after they add a package. Sometimes these can take a very long time (e.g. Makie.jl or DifferentialEquations.jl). Sure, you only have to do it once, but then you have to do it again every time there is an update. And whether you like it or not, it will make new users immediately think “Wow, it takes seconds to conda install something, Julia is comparatively so slow”. Also thinking about this recent post.
In my view, such frustrations are completely understandable and a clear barrier.
All this in mind, are there are any plans for the registry to store the precompiled binaries for different architectures (Python wheels-esque)? I saw some attempts to resolve this (Jumbo ) which is promising, but shouldn’t such tools be a “standard”?
I don’t think it has to be all or nothing. Just the LTS and latest stable version would satisfy most people. Even if I could do it myself locally in some Docker (like BinaryBuilder.jl tools for C libraries) and then just push those binaries to the registry with my package in some standard way, that could significantly improve my user experience
I don’t really get it myself so someone should correct me, but I was under the impression that independently AOT-compiled units like shared libraries can’t be optimized together, which is very different from how a Julia session optimizes within a world of all loaded modules, a type of whole-program optimization like AOT compilers’ link-time optimization from intermediate code. Our locally precompiled package images are thus highly dependent on what else is in our environment; we see this effect when installing more packages triggers precompilation of prior package images.
Therefore, there is no such thing as a LTS or latest stable precompilation binary because it does not only depend on the package’s version, but the versions of all its dependencies allowed within one of countless environments. It is hypothetically possible to distribute version-wise intermediate code prior to any whole-program optimization to save some time, but we would still need to locally optimize and compile the rest of the way, and it might not be meaningfully different from just distributing the source.
I would suggest making seperate enviroments for specific workflow, julia wont precompile without a change or update. So breaking up your main pkg enviroment to smaller ones can help with that. You can do that with julia > activate @Whatever and keep llvm type pkgs for example there and so on. I actually prefer the slow start and precompiling, it lets me know julia is checking and tracking it all, then works really fast, because to me the least time i need anything is during startup lol.
Precompiled Binaries (like LTS/Stable) are not feasible: Distributing a “pre-built binary” for a Julia package is impractical because it would only work for one specific combination of all its dependencies. One update to an API invalidates it. Julia is like a rolling release. LTS, can work for your enviroment with sysimage, juliac, pkg compiler. Julia is too dynamic. You want static enviroments or dynamic.
It’d be nice if someone who has worked on or otherwise had to deal with Pkg on a deeper level than routine usage chimes in, yeah.
I presume that’s why Jumbo isn’t installed as a package, but a project. I don’t know how the stdlib path works but it sounds like a deliberate restriction of changes to the dependencies, something we wouldn’t expect if we had add-ed the packages even with strict versions to an environment ourselves.
Conclusion: Pre-built binaries via the registry, in theory, could be possible, but implementing this proposal would require significant effort.
For now, [ANN] Jumbo - a scientific Julia distribution is the way to go if you want to avoid long pre-compilation times using a pre-defined set of packages.