Thank you, everyone, for voting! Given the strong preference for Jumbo, I have decided to go with that name. I’ve made an updated release that also includes CSV and JuMP packages. The release assets will be uploaded over the next 2 hours as GitHub CI completes the builds.
I’ll update the title and announcement with the new name and links once the builds finish.
Thank you Janis, this sounds absolutely perfect for me. I am using Julia in my university lectures and we have big problems with installation on the university machines: the university effectively deletes the user directory on log out. So all julia packages get deleted, so on new log in, you’re hit with a 30-minutes delay to reinstall everything…
Sounds like a custom Jumbo (which I would have hoped would have been renamed to Jukebox instead, it fits better) is the perfect solution. I will write here, or anywhere else you prefer, the outcome of my attempt to use Jumbo to solve the problem.
@Janis_Erdmanis Please be aware of Julia’s precompilation targets.
Cross references:
I already take thoose into account - AppBundler.jl/src/Utils/Stage.jl at f5aec5b1e61cb731954dd3fa1a000d3232dc6afa · PeaceFounder/AppBundler.jl · GitHub Have you had precompilation cache invalidation?
I overlooked AppBundler.jl. Just looked at Jumbo.
Have you had precompilation cache invalidation?
I do not use Jumbo.
JuSci ?
Juicy 
But the name decision has been taken, and Jumbo has been decided as the new name now.
Is there consensus on how often should Jumbo have updates? Considering it packs more than 800 packages, I think it should be on regular basis, i.e. once a week, once every two weeks? Preferably automated updates. Also Jumbo release name could be both Julia version and date so that if someone needs older Julia version bundled that it is easy to find it.
This is great and I’ve wanted something like it for a long time. Thank you so much! 
I can commit to releasing a new version every two months. This is straightforward, and I plan to streamline the process by creating a GitHub Action that automatically updates the project with the current Julia version and modifies the Project.toml version field. Once that’s in place, I’ll only need to click a few buttons in the web interface—and eventually, I may automate releases entirely.
The most pressing issue right now is code signing for distributions. Without it, installing a Jumbo distribution requires detailed workarounds, which isn’t ideal. I’d like to resolve this as soon as possible, but it’s frustrating: cheaper Windows code signing certificates only come with hardware tokens, which breaks CI workflows. I’m not keen on committing to manually downloading releases, signing them on my computer, and re-uploading them every two months—especially while paying for certificates long-term. That said, I may have access to a code signing certificate for about a year as part of developing the AppBundler project.
Is there any list of included packages? Would it make sense to make a file on github that lists them all including versions?
The Project.toml on the repo conveniently has both of those.
How so? I see there only 19 dependencies, but Jumbo should come with about 800 installed.
The 800 includes indirect dependencies you can’t import, skim the Manifest.toml and review the fundamentals here:
Though now I look at the project, my question is why not all of them have version constraints. Earlier it was mentioned that the stdlib path is used to prevent changes to the pre-installed dependencies, but wouldn’t it have been more informative to specify the direct dependencies’ versions without having to run Julia and Pkg.status?
The version constraints were added automatically to the Project.toml when packages were added. They may be removed from there in the future, but for now they provide a general sense of how fresh the included packages are. They are somewhat redundant here, as the repo already contains Manifest.toml which lists all dependencies.
If someone has the energy, one could build a static web page, preferably with Franklin.jl, which parses the Manifest.toml file and lists all dependencies in a user-readable form.
This would be unmaintainable by hand. At that point one would write a tool for updating, listing all dependecies in Project.toml which is what Manifest.toml already is for.
I agree that it’s technically redundant, but it’s fairly tough to spot the 19 direct dependencies among the 800, and there’s a reasonable ask right here for those versions in one visible place without having to install everything first. But you do have a point that this kind of modification to compat should be automated from the manifest somehow.
Perhaps the freeze() function of GitHub - ufechner7/PkgHelpers.jl: Helper functions for the Julia package manager might be able to do that?
I think this is a great idea if it keeps to assembling parts from the Registry. I’d hate to see it become a vehicle for fragmenting the language, however.
I’ll throw out another name: Joomba, which seems primarily a term for something pleasing to the eye.
pkg> compat --current maybe could do that. Coming in 1.13.