Thanks Janis! In the readme I couldn’t find any info about this, but what is the process for deciding which packages go into the published Jumbo releases?
Over the summer I’ll make a fork of Jumbo focused on JuliaDynamics packages so that I can use this in my lectures and alleviate the difficulties of Julia installation. I’ll post here how it goes!
Thanks! Making it easy for people to create their own forks for teaching needs is really the ultimate goal, so I’m glad to hear you’re planning one for JuliaDynamics.
The package selection is admittedly somewhat arbitrary. The core consists of developer-experience tools I use extensively myself (like Revise and Infiltrator — I may add more of these in the future), plus a mix of packages I relied on during my PhD and ones that impressed me at JuliaCon talks. It’s hard to draw a clean line, but the general heuristics I apply when considering a new inclusion are:
Anyone is welcome to open an issue proposing a new package, and I’ll evaluate it against those criteria. Looking forward to hearing how the JuliaDynamics fork goes!
Is there any chance of getting Jumbo integrated with juliaup?
Like:
juliaup add jumbo
juliaup default jumbo
?
That would make it easier for people to try out Jumbo.
This isn’t something I’m planning to work on myself, but if someone wants to take it on, I’d be happy to assist. There may also be an opportunity to distribute Julia distributions as Pkg apps by creating a special main function. Efforts could then be directed toward distributing the compilation cache of Pkg.apps, which would make the existing distribution method redundant.
I installed Jumbo on Ubuntu 24.04. I can launch it from the GUI. But how can I launch it from the command line? And where does it actually get installed?
On Linux, you can usually launch Jumbo from the command line simply by typing jumbo as the Snap binary directory is in your PATH, similar to how you would run jumbo.exe on Windows. When installed via Snap on Ubuntu 24.04, the executable is typically located under /snap/jumbo/current/, which is symlinked into your system path, so you don’t need to reference the full install location directly. If you want to confirm where it’s coming from, you can check Sys.BINDIR and also Base.DEPOT_PATH.
I have checked out our package VortexStepMethod.jl. It is the current directory.
git clone https://github.com/OpenSourceAWE/VortexStepMethod.jl.git
cd VortexStepMethod.jl
If I do:
jumbo --project
and then
using VortexStepMethod
I get an error message.
If I do:
julia --project
and then
using VortexStepMethod
it works.
What could be the reason?
In other words, can I use Jumbo together with only locally available Packages?
Thanks for pointing this out! This is a significant oversight — when setting Base.ACTIVE_PROJECT[] to the user data directory (see startup.jl#L19), it overrides the --project. I’ll address this in the next release. For now you can do activate VortexStepMethod after oppening jumbo.
Try the patched version which is currently being built - Build Release Assets · JanisErdmanis/Jumbo@34c6b5e · GitHub
I forked your repo and tried to run
julia --project=meta meta/build.jl --build-dir=build
locally as explained in the README.md file. But the file meta/build.jl does not exist. What could be the reason?
Thanks for catching that — I’ve now updated the README. You can build the distribution locally with:
appbundler build . --build-dir=build --selfsign
I am getting an error:
ufechner@framework:~/repos/Jumbo$ time julia --project=meta -m AppBundler build . --build-dir=build --selfsign
[ Info: Initializing Snap staging layout...
[ Info: Installing app into staging area...
Fetching sources for julia-1.12.6-Pkg.BinaryPlatforms.Linux(Platform("x86_64", "linux"; libc = "glibc"))
ERROR: RequestError: Operation too slow. Less than 1 bytes/sec transferred the last 20 seconds while requesting https://julialang-s3.julialang.org/bin/linux/x64/1.12/julia-1.12.6-linux-x86_64.tar.gz
Stacktrace:
[1] (::Downloads.var"#26#27"{IOStream, Base.DevNull, Nothing, Vector{Pair{String, String}}, Float64, Nothing, Bool, Nothing, Bool, Nothing, String, Bool, Bool})(easy::Downloads.Curl.Easy)
@ Downloads ~/.julia/juliaup/julia-1.12.6+0.x64.linux.gnu/share/julia/stdlib/v1.12/Downloads/src/Downloads.jl:479
[2] with_handle(f::Downloads.var"#26#27"{IOStream, Base.DevNull, Nothing, Vector{Pair{String, String}}, Float64, Nothing, Bool, Nothing, Bool, Nothing, String, Bool, Bool}, handle::Downloads.Curl.Easy)
@ Downloads.Curl ~/.julia/juliaup/julia-1.12.6+0.x64.linux.gnu/share/julia/stdlib/v1.12/Downloads/src/Curl/Curl.jl:105
[3] #24
@ ~/.julia/juliaup/julia-1.12.6+0.x64.linux.gnu/share/julia/stdlib/v1.12/Downloads/src/Downloads.jl:390 [inlined]
[4] arg_write(f::Downloads.var"#24#25"{Base.DevNull, Nothing, Vector{Pair{String, String}}, Float64, Nothing, Bool, Nothing, Bool, Nothing, String, Bool, Bool}, arg::IOStream)
@ ArgTools ~/.julia/juliaup/julia-1.12.6+0.x64.linux.gnu/share/julia/stdlib/v1.12/ArgTools/src/ArgTools.jl:134
[5] #22
@ ~/.julia/juliaup/julia-1.12.6+0.x64.linux.gnu/share/julia/stdlib/v1.12/Downloads/src/Downloads.jl:389 [inlined]
[6] arg_read
@ ~/.julia/juliaup/julia-1.12.6+0.x64.linux.gnu/share/julia/stdlib/v1.12/ArgTools/src/ArgTools.jl:76 [inlined]
[7] request(url::String; input::Nothing, output::IOStream, method::Nothing, headers::Vector{Pair{String, String}}, timeout::Float64, progress::Nothing, verbose::Bool, debug::Nothing, throw::Bool, downloader::Nothing, interrupt::Nothing)
@ Downloads ~/.julia/juliaup/julia-1.12.6+0.x64.linux.gnu/share/julia/stdlib/v1.12/Downloads/src/Downloads.jl:388
[8] request
@ ~/.julia/juliaup/julia-1.12.6+0.x64.linux.gnu/share/julia/stdlib/v1.12/Downloads/src/Downloads.jl:355 [inlined]
[9] (::Downloads.var"#7#8"{Nothing, Vector{Pair{String, String}}, Float64, Nothing, Bool, Nothing, Nothing, String})(output::IOStream)
@ Downloads ~/.julia/juliaup/julia-1.12.6+0.x64.linux.gnu/share/julia/stdlib/v1.12/Downloads/src/Downloads.jl:273
[10] open(f::Downloads.var"#7#8"{Nothing, Vector{Pair{String, String}}, Float64, Nothing, Bool, Nothing, Nothing, String}, args::String; kwargs::@Kwargs{write::Bool, lock::Bool})
@ Base ./io.jl:412
[11] open_nolock
@ ~/.julia/juliaup/julia-1.12.6+0.x64.linux.gnu/share/julia/stdlib/v1.12/ArgTools/src/ArgTools.jl:35 [inlined]
[12] arg_write(f::Function, arg::String)
@ ArgTools ~/.julia/juliaup/julia-1.12.6+0.x64.linux.gnu/share/julia/stdlib/v1.12/ArgTools/src/ArgTools.jl:103
[13] #download#5
@ ~/.julia/juliaup/julia-1.12.6+0.x64.linux.gnu/share/julia/stdlib/v1.12/Downloads/src/Downloads.jl:272 [inlined]
[14] download
@ ~/.julia/juliaup/julia-1.12.6+0.x64.linux.gnu/share/julia/stdlib/v1.12/Downloads/src/Downloads.jl:252 [inlined]
[15] install_julia(platform::Pkg.BinaryPlatforms.Linux, julia_dir::String; version::VersionNumber)
@ AppBundler.Resources ~/.julia/packages/AppBundler/CNmKH/src/bundlers/Resources.jl:522
[16] fetch(project::String, destination::String; platform::Pkg.BinaryPlatforms.Linux, include_lazy_artifacts::Bool, stdlib_dir::String)
@ AppBundler.Resources ~/.julia/packages/AppBundler/CNmKH/src/bundlers/Resources.jl:665
[17] stage(product::AppBundler.JuliaImg.JuliaImgBundle, destination::String; platform::Pkg.BinaryPlatforms.Linux, cpu_target::String, runtime_mode::String, app_name::String, bundle_identifier::String)
@ AppBundler.JuliaImg ~/.julia/packages/AppBundler/CNmKH/src/bundlers/JuliaImg/JuliaImg.jl:469
[18] (::AppBundler.var"#37#38"{AppBundler.JuliaImg.JuliaImgBundle, AppBundler.Snap})(app_stage::String)
@ AppBundler ~/.julia/packages/AppBundler/CNmKH/src/recipes.jl:59
[19] bundle(setup::AppBundler.var"#37#38"{AppBundler.JuliaImg.JuliaImgBundle, AppBundler.Snap}, snap::AppBundler.Snap, destination::String; force::Bool)
@ AppBundler ~/.julia/packages/AppBundler/CNmKH/src/bundle.jl:600
[20] bundle
@ ~/.julia/packages/AppBundler/CNmKH/src/bundle.jl:585 [inlined]
[21] bundle(product::AppBundler.JuliaImg.JuliaImgBundle, snap::AppBundler.Snap, destination::String; force::Bool)
@ AppBundler ~/.julia/packages/AppBundler/CNmKH/src/recipes.jl:54
[22] main_build(ARGS::Vector{String}; sources_dir::String)
@ AppBundler ~/.julia/packages/AppBundler/CNmKH/src/main.jl:132
[23] main_build
@ ~/.julia/packages/AppBundler/CNmKH/src/main.jl:44 [inlined]
[24] main(ARGS::Vector{String})
@ AppBundler ~/.julia/packages/AppBundler/CNmKH/src/main.jl:22
[25] _start()
@ Base ./client.jl:556
real 0m33,964s
user 0m13,618s
sys 0m0,837s
Any idea?
Looks like a network issue. Try again later. Check https://julialang-s3.julialang.org/bin/linux/x64/1.12/julia-1.12.6-linux-x86_64.tar.gz
The artifacts of this build are expired by now. Did they fix the --project issue?
In my testing after the fix, --project now works, but the workflow still needs testing. I’ve retriggered the GitHub Actions build, and once it finishes, it should also upload the assets to the v26.04.12 release.
Perhaps @davidanthoff can be summoned to comment on this? Having juliaup add jumbo-v1.0 could be a huge boon to student adoption.
The current form of distribution does not seem particularly well-suited for inclusion in juliaup without introducing a maintenance burden on their side. A better approach would be to package Jumbo Julia as a Pkg app, which involves some trickery in @main to set up Base.DEPOT_PATH, Base.LOAD_PATH, and Base.STDLIB, then revert to the REPL once that’s done. From there, the problem could be approached in the broader sense of how to distribute Pkg app caches in general, while juliaup could add support for installing Pkg apps via something like juliaup app add jumbo.