`juliaup` for for Mac and Linux

Tooling
,
1

From what I can tell, @davidanthoff recently rewrote juliaup in rust, which was to make it available on Mac and Linux (Thank you, the manager is fantastic). Is there any information as to when?

3 Likes
2

idk about mac user these days (home brew still okay?) Linux distros has pkg manager I don’t want each application to self upgrade with some privileged permission.

if you’re using Arch based distribution, checkout julia-bin in AUR

3

Brew works fine, it has 1.6.2 right now, so i guess it is working

4

But aren’t you then stuck with whichever Julia version your package manager gives you, which could be ancient, even several years old?

One of the reasons (not the only) I gave up on Linux was that I had all sort of problems getting up-to-date software packages. I never managed to install an up-to-date LaTeX, for example.

5

https://aur.archlinux.org/ is user maintained, but the work flow integrates with your pkg manager and you probably use it already whenever you don’t want to build software youself…

AUR (en) - julia-bin is 1.6.2 now

And for example:
AUR (en) - julia-beta-bin is maintained by @vchuravy

For Arch-based system, up-to-date is not the main problem, the problem is you don’t want to use a julia that’s compiled by “them”. AFAIK homebrew doesn’t solve this problem:
https://github.com/Homebrew/homebrew-core/blob/cdf9c5aea0b0de477d6755ecba73beaffb10e679/Formula/julia.rb#L136

cask does use binary directly, just like AUR

6

OK, so dumb question from someone who barely uses Linux now: will that work on ubuntu?

7

Ubuntu has their own stuff called PPA that once had a Julia source maintained by @staticfloat but seems abandoned now. PPA has poorer (you need to manually add PPA source) integration with apt, but at least it upgrades as part of apt update routine and if you’re a power user you already have PPA sources added for other stuff.

8

This is one reason why I use Archlinux on my work system. You get a rolling release (so always up to date software) + the AUR.

On servers etc I still tend to use Debian/Ubuntu. For long term stability.

So yes you can have your cake and eat it to.

2 Likes
9

Generally tools like this do everything on the user level by default, so they don’t need any privilege escalation. Definitely true for rustup (upon which juliaup is based), though I’m not 100% sure about juliaup (I’d be shocked if it behaves differently though, due to the way it works).

As for why you would want to use a tool like this rather than the system package manager: This tool allows you to install multiple versions of Julia side-by-side, manage them all together, and switch back and forth between them at will. This means you can test your code with (theoretically) every version of Julia that has been released so far. Most system package managers will either include the stable Julia or some version of Julia which approximates the latest one, if you’re lucky it will allow you to install both at the same time, and if you’re really lucky it will have the actual latest version packaged. This (i.e. juliaup) is useful for general development (so that you don’t have to spin up a docker container to test an older version of Julia), but super useful if a user submits a bug report against a version of Julia that does not match the version you have.

The context is here and here, so in the last two weeks or so. Worth pointing out that it’s not cross-platform yet, the developer just thinks that (edit: on a second read this sounds a little negative, I just meant to paraphrase what was said in the pull request) it should be easier to make it cross-platform.

4 Likes
10

For most platforms there is still quite a distance to go before we can declare success, some major parts that we really need for a smooth operation are not yet implemented. On Windows we get those features from the store. But, it actually should all work on Archlinux already, @simeonschaub added support for that a while ago and we now automatically publish juliaup to AUR as part of our normal build process.

The question of how this all relates to existing package managers is an interesting one :slight_smile: Here is my take: the way I think about juliaup is that it handles Julia itself in a similar way in which we handle binary artifacts. So if you use juliaup, it provides/“owns” 1) the main julia command and 2) the juliaup command (that is similar to the Julia package manager). Specific Julia versions become more like Julia packages, i.e. you can use different ones, switch between them etc.

I do think this model enables scenarios that we would never be able to solve via system package managers. The primary ones are really the version multiplexer, i.e. the support of having multiple Julia versions on your system at the same time, being able to easily switch between them etc. In the future I also hope that we can add support for encoding a Julia version in Manifest.toml that can be picked up by juliaup, see here. Our package manager already enables fantastic reproducibility, but very much conditional on you using the correct Julia version. I think with the Juliaup design we will be able to extend our reproducibility story to also include Julia itself. There are also features like native support for different channels (lts, and release for example) that are useful.

I do want to integrate all of this with system package managers, though. But I think the level where that should happen is that these system package managers deploy Juliaup itself. I could also imagine a future where Juliaup becomes the official, default deployment mechanism for Julia at which point commands like brew install julia or sudo apt install julia would actually install Juliaup. But for now brew install juliaup or apt install juliaup I think would also work. On Windows and Archlinux that is the model right now: Juliaup is deployed and updated via the system native package manager (Windows Store and AUR respectively).

We are also currently working on features that allow users to install Juliaup itself without a system package manager, in the spirit of how you install rustup via a shell script on Linux and Mac. For those scenarios we need to implement a self-update mechanism for Juliaup, and that is the main piece that is still missing before this self installer is ready for public use.

Juliaup installs Julia versions itself into the Julia depot, so there should not be any need for elevated privileges, it is really very similar to how Julia installs binary artifacts.

14 Likes
11

That would be great!

1 Like
12

I have been using jill to manage my Julia installation. I’m no expert, but it seems to be reliable and install everything correctly with full control over release version.

4 Likes
13

jill is fantastic and was certainly a major inspiration for juliaup. The one thing that was important to me, though, was to not have a dependency on something like Python. For example, on Windows (where this whole juliaup experiment started) the whole Python setup situation is such a mess and has caused such an endless stream of headaches in classes that I taught that at this point I really, really am trying hard to enable as many important Julia scenarios without a Python dependency (the recent Jupyter notebook support in VS Code is the other side of that coin, in many ways).

The way I think about this is that jill.py really demonstrated how valuable a version multiplexer would be for Julia, and in many ways Juliaup is now trying to replicate a lot of those features, just without a Python dependency. And of course the whole Windows Store integration (which really was the starting point for Juliaup).

17 Likes
14

I’ll just like to mention scoop here (Windows only). It’s a great tool to use, and it supports adding your own repositories or “buckets”, and with your own repository you can control what version of the application you want to use (although you still have to update .json files yourself). Maintaining multiple versions of the same application will probably be harder.

I agree that on Windows 10 the Python dependency can be a huge problem, and will be especially problematic for new users. For me, scoop is great especially when I do not need multiple versions of julia, and I don’t have to deal with UAC or the windows store.

(Maybe support juliaup installation through scoop’s main bucket?)

15

I am using Ubuntu on a lot of machines, and installing Julia (and keeping it up to date) is simple:

bash -ci "$(curl -fsSL https://raw.githubusercontent.com/abelsiqueira/jill/master/jill.sh)"
16

Well… for jill.py it’s even simpler after you have it installed pip install jill

jill install

Not to mention that jill.py supports all platforms.

1 Like
17

Well, but you can only use pip if you have a working Python installation… And a working pip program… And sometimes it is called pip3 …

One of the reasons for me for using Julia is to avoid the hassle with broken Python installations…
So I prefer the bash version of jill.

18

That’s very true. And jill.py is a tradeoff between cross-platform and some dependencies. And that’s all because my knowledge is quite limited when I start the jill.py project 3 years ago.

Yet still, I would say having a working python installation nowadays should be not a big issue. Efforts are made in jill.py to not depend on too many dependencies (especially those with binary dependencies).

Of course, jill.sh works quite well for Linux (32bit/64bit). I enjoyed it a lot before I started my python fork.

1 Like
19

scoop is nice, but its future is not really clear to me, given that winget now exists? The winget team is almost done (if I understand things correctly) adding support for installing Windows Store stuff out-of-the-box. Once that update has shipped, you’ll be able to skip the store UI entirely and just run winget install julia and it will install exactly the same thing that you get when you install juliaup from the store. And given that winget now ships by default on all Windows 10 versions, I think that will then really be the smoothest option on Windows.

We are currently working on a solution for juliaup that is very similar to that to get it initially installed for situations where you can’t get it from your system package manager on Linux or Mac, the details are here. The plan is that once you have installed the initial version via such a downloaded script, you update Julia versions with juliaup update and you update juliaup itself via juliaup self update (the latter does not yet exist, though). But I think the medium term goal is to get it into as many “system” package managers as possible, like with AUR for Archlinux.

2 Likes
20

FWIW I just installed juliaup on my m1 macbook from source-- it wasn’t too bad, though obviously more involved than once there’s a nice distribution story.

  1. I cloned the repo, git clone https://github.com/JuliaLang/juliaup
  2. I installed rust via https://rustup.rs/
  3. In the juliaup directory, I ran cargo install --target x86_64-apple-darwin --path . (well actually I messed around a bit building it and trying to figure out the right invocations, but I think that’s the only one you really need).
  4. Then I ran juliaup add release to install Julia 1.6.2, juliaup default release to make that the default,
  5. and added alias julia=julialauncher to my .zshrc, and removed my previous julia from my PATH.

Now julia launches julia through julialauncher, and I can configure where it’s pointed by juliaup.

3 Likes