This is both a big and small update at the same time. In terms of user facing changes, it is very minimal:
There is a progress bar for downloads.
There are new -h and --help flags.
Generally the command line interface is a bit richer.
Under the hood, this is a complete rewrite Everything is written in Rust now. There are some major benefits to this new approach:
Everything is much smaller. The previous juliaup was a couple hundered MB, now it is about 2.5 MB. When you install from the store, the total size now is what you would expect, a little more than 100 MB. Updates to juliaup that donāt include updates to the bundled Julia version are really small and fast now.
juliaup has excellent startup performance
The code is much more robust. Rust really forces you to handle errors and catches many via its static type system.
This all paves the way to a completely cross-platform version of juliaup.
No more C++! The launcher was previously written in C++ (because it needs to be really as fast as possible), but now is also written in Rust, which makes it way, way simpler.
At the same time, a rewrite always is a risk, and Iām sure I outsmarted Rustās type checker somewhere and managed to introduce some new bugs. So, please be on the lookout for those and report them either here on even better over at https://github.com/julialang/juliaup. Iāll be monitoring both places and will try to fix anything that comes up quickly.
How do you get the new version? Well, just wait, it is auto-update You could also check in the Windows Store for updates, but it will probably take a little longer before the files have made it through the store submission pipeline.
Ah, I forgot to remove something there from an older version. Two options: 1) Iām going to push out an update that fixes this very soon, 2) you can delete a file called juliaup-versionsdb-winnt-x64.json in your ~/.julia/juliaup folder and then it should also be fixed.
I also hoped to have something like rustup over jill.py, avoiding an extra step installing pip3 would be VERY convenient especially when I use AWS instances pip3 isnāt always available in the AMI.
I was hoping to do this in pure Julia tho so I made a very experimental thing called Ion: https://github.com/Roger-luo/IonCLI.jl and I havenāt got much time to polish it recently. Itās a binary built in pure Julia and thus has a much larger size. And my hope is to get smaller binary when the Julia runtime separated from codegen and llvm. I was hoping it to be more a CLI for more complicated julia workflows like some of the features cargo provides.
Iām very excited to try out juliaup it seems much stable than Ion and smaller too. Thanks for making this!
Yeah, we clearly need some solution when the Windows Store is blockedā¦ My best guess right now is that we should try to make the shell/script based installer that we have on Linux and Mac also work on Windows for those situations.
I do think that in those scenarios weāll have to modify PATH manually, the entire execution alias thing really only works if a piece of software is installed via an MSIXā¦ The only other option I wanted to recheck is whether standalone MSIX installs now work without the sandbox, in which case we could also try that.
Thankyou @carstenbauer I really was not hassling. I am just curious about the process - if we expect folks to use juliaup we as a community should check that updates are arriving.
I would also be curious to know the process. I saw that 1.8.0-beta1 was actually tagged several days ago. I would have thought that perhaps juliaup was somewhat automated and picked up the the new release right away, but I guess the process is much more manual.
The process is probably a bit too convoluted at the moment. I monitor the release channel on Slack and try to understand when things are ready in terms of official builds being available for downloads, but there are always many steps discussed there, and it is not entirely clear to me when I can start to move things on the juliaup side. But when I have the sense that things are ready, I bump a build for juliaup. It takes about 10-15 minutes for the build to finish, then I deploy it to the dev channel of juliaup itself. For that build to make it through the Windows Store infrastructure it typically takes a few hours. Once that has happened, I test whether everything works, and then I trigger the release of the build to everyone. At that point the build has to go through the Windows Store process again, and that typically also takes a few hours, although with the latest build it was more like a day.
Ideally there would be one source of truth for the statuses of the releases. I recall that you did not want to use the file (versions.json) that all the rest of the ecosystem use for this. I think this was due to file size? Surely, that could be worked around by e.g publishing a hash if the file and only redownload it on changes.
I definitely want things to eventually just depend on versions.json and get rid of all manual steps. I think we want to get there in two phases:
Some changes to versions.json will always require release of a new complete version of juliaup, i.e. pushing of a new version to the store, the various package managers etc. In particular, whenever the release version of Julia changes, that is the case, because juliaup internally ships/bundles that particular build. I think to automate this more, we probably need some way that an update to versions.json triggers a GitHub workflow in the juliaup repo, and that workflow then prepares a PR for a new version of juliaup or something like that. I could see a scenario where things are fully automated with no user input for this, but maybe that is further down the road, for now it would just be great if there was something automatically kicked off.
A more refined second solution would allow the juliaup client to download new version info without updating juliaup itself. This would be useful whenever a new Julia build is released that is not the main released version at the moment, i.e. new LTS versions or prerelease builds. It would also be especially useful down the road if we succeed in putting juliaup into say the default Ubuntu package manger that apt interacts with, where we wonāt be able to update juliaup regularly. This entire scenario is much more complicated, though. We need to deal with things like download size, the size of the version DB on disc (to make sure we donāt spend too much time checking things from a large JSON file whenever julia launches), the stability of the schema of things, handling race conditions on the update side of the version DB file, the interaction of updates to the versions.json file with updates to juliaup itself etc. An earlier version of juliaup actually had all of this implemented, but it was too brittle, so I removed it until we can implement a more robust solution.
I think for now just having the first option would already be great. Having the second option would at the moment be a nice to have things, but wouldnāt actually make the end-user experience that different, so Iām tempted to wait a bit with that. I do think we really need the second part if we get serious about getting juliaup into slower moving package managers, thoughā¦
Everything is written in Rust now. There are some major benefits to this new approach: