Jumbo (formerly JuBox) is a Julia distribution that comes with commonly used scientific packages out of the box. Load Makie, DifferentialEquations, or any included package immediately—all pre-compiled on GitHub CI and ready to use. Additional packages can be installed via Pkg without triggering recompilation of pre-installed packages.
This can be useful in educational settings to prevent precompilation of heavy packages during interactive computer lab sessions, and helps newcomers get started with popular ecosystem packages for a smoother first-time experience.
What’s included
Julia 1.12 with approximately 800 pre-compiled packages
Revise and Infiltrator configured to launch automatically
Native installers for Linux, macOS, and Windows
Getting started
Download the installer for your platform and CPU architecture from the release page. Note that macOS and Windows installers are self-signed and require additional installation steps—see the README for details. Once installed, launch JuBox from the desktop menu.
Custom distributions
The Jumbo repository serves as a template for creating tailored distributions. Fork it, modify the Project.toml with your preferred packages, and run the “Build Release Assets” GitHub Actions workflow to generate installers for all platforms.
The packages are put in the stdlib path, so they are picked up by the Pkg resolver. I had an issue with the Statistics package, which has a special status of being upgradable. That for instance caused DifferentialEquations to recompile after adding a Luxor. Eventually, I fixed this issue by clearing the Pkg.Types.UPGRADABLE_STDLIBS list at startup.
There is also an interesting opportunity for users to upgrade specific packages in their environment by manually pushing them at Pkg.Types.UPGRADABLE_STDLIBS before updating.
I’m not sure; I personally use Emacs. If the VSCode extension allows setting the Julia executable path, that might be all that’s needed. You might also need to install a language server, which can be added to the distribution.
Woudn’t be simpler for the user to get it as a channel of juliaup ? I am a very recent user of juliaup (always just used symlinks..), but I understood juliaup has now 1-dimensional concept of version, perhaps one would like to make it a 2-dimensional concept of [distribution],[version] where distribution could be the core one, your scientific one or whatever…
Yes, a dedicated juliaup channel would make much more sense! Here I am creating MISX, DMG, and Snap installers because it was an easy opportunity for the AppBundler.jl project. Currently, I am looking at JuBox as a prototype to see whether it is genuinely desirable and would be used before allocating more development resources to it.
I have also seen discussions about distributing pkgimages via Pkg itself, and hence, distribution bundling may be a temporary solution before that arrives.
I think this is a great idea in general, especially in classroom environments. I must say though that the name you’ve chosen, when pronounced aloud, makes me uneasy.
There does not seem to be any historical record with this combination. Hence I don’t understand why should one feel uneasy pronouncing the JuBox aloud. There is even a website jew-box.com
The phrase “jew box” does not have an established or widely recognized meaning as a standalone term in standard dictionaries or common usage. However, from the search results:
It may be a mistaken or shortened form related to “jewel box,” which means a small box or case designed to hold jewelry, or a clear plastic case for CDs or DVDs.
One source from Urban Dictionary uses “Jew box” as a slang synonym for television, reflecting a controversial or offensive connotation based on claims about media ownership, but this is not a formal or respectful meaning.
Another source refers to an exclusionary metaphor “Jew box” in a critical context, where ideas that do not fit a perceived category are excluded, indicating a figurative or polemical use but without a fixed dictionary definition.
From my point of view, it’s not super problematic, but perhaps a little bit.
Another association I had was “Jukebox”.
Perhaps rename it to JewelBox? Well, I’m not sure, but you have some very valuable items in your box. Or just SciJulia?
By the way, I think this is a very promising project!
The package naming guidelines discourage package names starting with Julia or Ju for a variety of reasons that have been discussed before. I do believe this is not a package for registration. I do feel like these rules have generally given us good package names.
Thank you for the feedback and for sharing the TechnicalComputeBundle reference—it’s definitely in a similar spirit to what I’m doing here. Interestingly, that project could also use AppBundler.jl to create their own bundled distribution from their curated Project.toml.
I appreciate the point about package naming guidelines. To clarify: JuBox isn’t intended for package registration. It’s a distribution/installer project, similar in concept to Anaconda for Python or RStudio for R—a bundled environment rather than a registered Julia package. The repository creates standalone installers that users download and run, not something they’d add through Pkg.
Since it is not a package, I found it appropriate to prefix the distribution name with Ju, following how Linux distributions name themselves, such as Linux Mint and Arch Linux, which does not imply affiliation with the Linux project itself. The prefix also makes it easy to start Julia in the terminal using ju\Tab, which I find convenient for listing alongside existing Julia installations.
If I understand correctly, if I install your distribution, it installs Julia 1.12 + roughly 700 pre-compiled packages in a global environment. What if one adds another package which then triggers pre-compilation across all those packages? Or are you saying this installs a system image of Julia 1.12 with those packages baked in (though I guess it becomes impossible to change/upgrade their versions then).
Also, I also find the name to be a bit uncomfortable to pronounce. I would also suggest renaming it.
Recompilation is avoided by resolving newly installed packages using the pre-installed dependencies, which are equivalent to standard libraries. From the user’s perspective, they behave similarly as part of the sysimage, except that one does not need to load them all at once, saving users’ memory.
However, this approach can make some packages with compatibility constraints uninstallable. To address this, users can submit simple PRs to update compatibility bounds for dependencies, which ultimately benefits the ecosystem.
Updating packages with Pkg would trigger precompilatiom of a large number of updated packages, so users should instead wait for an update of the entire distribution released on your GitHub repo. Is that right?
Updating packages that are bundled with the distribution is not possible, hence users indeed need to wait for the distribution update. There is also nothing wrong with users forking the repo and building the releases themselves, which is extremely easy to do.
