I love this idea. About a year ago, I was trying to take the technical compute bundle and seeing how much you can pack into a standard sysimage to make Julia fast for me (this seems largely impossible because sys images are largely broken beyond 2GB and once you throw Makie & DifferentialEquations in there, you are most of the way to 2GB). I’ll have to try your stuff on that.
For whatever reason, Julia for me spends half of it’s life compiling and … I’m sorry to say … but it’s becoming a big let down. Between LLMs writing C++ way faster and writing python way better, I do worry about Julia, so it’s so nice to see this idea as a way to make it better.
When looking at packages, one big missing package in CSV… (or is there another way to read CSV files in Julia these days?), otherwise, I’ve been very happy with the selection so far.
Please keep up the effort and let me know if I can help. My time has been short this past year, but this is the kind of thing I want to see succeed (especially for teaching).
Another big bummer at the moment is you need to really work to install this on MacOS. Is there a way to get it notarized or whatever the Mac stuff wants?
I tried installing it, and it seems to have automatically installed to drive C? Can it be installed to another specified path, as I don’t have much free space left on my C drive?
Ok, I’ve heard from several people about issues with the name, so I’m open to reconsidering it. To preserve the ju\Tab workflow in the terminal, I’ve explored some alternatives (with help from Claude). Here are the options I’m considering:
JuBox (current name)
JuKit
Jumbo
Other option (please comment below)
0voters
Feel free to vote for up to two options. If you have other suggestions, please share them in the comments!
Ok. I have opened a pool for the name; feel free to check the alternatives.
Since AppBundler works with pkgimages, it can sustain significantly larger bundles. One could still pay attention to CI memory limits, but I have not yet reached them.
The selection of packages was generally motivated by the time it takes to precompile the package and how well it represents the Julia ecosystem. I am open to adding more packages along the way. The only constraint for me is that added packages should not impose upper compat bounds that require the use of downgraded dependencies.
Regarding CSV, it can be added with little precompilation pain on top of the existing distribution. Hence I don’t see it particulalrly valuable to include in the distribution. Furthermore, there are already DataFrames and DelimitedFiles.
The notarization requires an Apple Developer account, which costs 99 euros/year. Based on the feedback I received from this post, I will look into getting one to sign and notarise the distribution properly. It may work outside the box, or additional work may be required on the AppBundler side, as Apple may implement stricter verification, as I have expected. However, I am not sure I will complete this before the new year, as I have a lot of remaining work to do for the AppBundler.jl, which is currently funded by NLNET.
For Windows, I am fairly certain that a valid code signing certificate is all that is needed for making MSIX bundle installation simple. However, the issue is that these code signing certificates can be costly, ranging from €200 to €300 annually. Recently, I came across Code Signing - Certum Shop, which seems to offer a good deal at 25 euros per year for open-source projects. However, it appears that you do not receive a simple PFX file for signing, but rather a USB dongle, which complicates the GitHub CI automatic release process.
How about JulBox - keeps it similar to the current name, but sounds more like “jewel box”, and the imagery can play with the idea of this being like a treasure chest of useful packages.
‘JulBox’ makes me think of vape pens, a brand name of which is “Juul”. If I didn’t otherwise know the context I would be dissuaded from interacting. That’s just my take.
I’m leaning towards Jumbo because of the great elephant metaphor - Jumbo - Wikipedia. Elephants are big and have excellent memory, remembering their old paths. For the distribution tool, the “bigness” can represent the number of packages it bundles, while the “memory” relates to the pkgimages it stores and consistently reuses.
Jukebox is also fine, although it does make you think of a music player. JulBox could work too. I’ll probably create another poll later to also include theese options.
I almost voted for Jumbo as well because it’s a cute name that’s easy to remember, but I realised that if I saw a project called Jumbo, my subconscious expectation would automatically be of something heavy (in an unwieldy way) and slow-moving, along with the “bigness”/batteries-included positive side of it.
But to be honest, I don’t think the name bikesheds matter too much in the long run, and people get used to any name if the project is successful/useful enough (“Python”, “Mongo”, “Wikipedia” and many others have been criticised for their naming for a time, before they got popular and people stopped looking at them as strange new names), so I’m not strongly against any name here.
I saw this list and I think that something more along the lines of “JulSci” or “JulSciBox” or “JulSciComplete” might make more sense. Literally, a bit more literal.
The following instructions are for end users installing your built applications.
text in the README and for a while thought I misunderstood what this was - it seemed like this was only a way to build a custom Julia using CI, and doesn’t offer its own built set. Then I re-read the “Getting Started” section here and realised my original understanding was the correct one, that this does offer a custom-built Julia of its own - then Github UI confused me again (I’m an easily confused person sometimes ). It seems like Github collapses the Assets section of the release page for prereleases, so it seemed again like there was nothing to download, until I tried clicking the small Assets text near the bottom (with the Github-typical misaligned arrow next to it).
It might be worth rewording the Installation section a bit to clarify that this does come with a built Julia, linking to the releases page there, and perhaps mentioning the Assets section explicitly too.
Ohh. I copied that part from the AppBundler.jl readme and forgot switch to the context where users are the main persona. I updated the note on README so it would be less confusing.
I am curious about how the distribution would work with projects. Are all the package versions locked to whatever is bundled? How would that interact with an existing manifest file?
Yes, the package versions are locked in the distribution. If you try to resolve with an outdated Manifest, you’ll get an error. Just run ]up to update your dependencies. For reproducibility, I recommend using Julia installed through juliaup.
This seems pretty cool. Big projects like DifferentialEquations always take a lot of time in pre-compilation. I think some kind of binary distribution is necessary.
I don’t know why it has to start with ‘Ju’ at all, we know it’s Julia. If you must use ‘Julia’, how about Julia2Go.jl as in a take away meal. Or JuliaSci2Go.jl I would not want the name conflated with SciML.jl or such-like. I get the ‘box’ thing, you want to have it as an ‘out-of-the-box’ ready to go version. So my vote would be for Julia2Go.jl
). It seems like Github