# \`juliaup\` for for Mac and Linux

**URL:** <https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721>\
**Category:** Tooling\
**Tags:** linux, juliaup\
**Created:** [August 20, 2021, 10:17am UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721 "2021-08-20T10:17:43Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![TheLateKronos](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thelatekronos/32/12824_2.png) [@TheLateKronos](https://discourse.julialang.org/u/TheLateKronos)\
**Post date:** [August 20, 2021, 10:17am UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/1 "2021-08-20T10:17:43Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [August 20, 2021, 12:46pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/2 "2021-08-20T12:46:50Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![gbaraldi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gbaraldi/32/22101_2.png) [@gbaraldi](https://discourse.julialang.org/u/gbaraldi)\
**Post date:** [August 20, 2021, 1:19pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/3 "2021-08-20T13:19:01Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [August 20, 2021, 1:28pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/4 "2021-08-20T13:28:05Z")

</div>

> [@jling](#):
>
> Linux distros has pkg manager I don’t want each application to self upgrade with some privileged permission.

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.

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [August 20, 2021, 1:30pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/5 "2021-08-20T13:30:17Z")

</div>

[https://aur.archlinux.org/](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](https://aur.archlinux.org/packages/julia-bin/) is 1.6.2 now

And for example:  
[AUR (en) - julia-beta-bin](https://aur.archlinux.org/packages/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](https://github.com/Homebrew/homebrew-core/blob/cdf9c5aea0b0de477d6755ecba73beaffb10e679/Formula/julia.rb#L136)

cask does use binary directly, just like AUR

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [August 20, 2021, 1:32pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/6 "2021-08-20T13:32:22Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [August 20, 2021, 1:35pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/7 "2021-08-20T13:35:35Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![vchuravy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vchuravy/32/8_2.png) [@vchuravy](https://discourse.julialang.org/u/vchuravy)\
**Post date:** [August 20, 2021, 1:40pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/8 "2021-08-20T13:40:12Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![seamsay](https://avatars.discourse-cdn.com/v4/letter/s/f475e1/32.png) [@seamsay](https://discourse.julialang.org/u/seamsay)\
**Post date:** [August 20, 2021, 3:53pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/9 "2021-08-20T15:53:41Z")

</div>

> [@jling](#):
>
> application to self upgrade with some privileged permission.

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.

> [@TheLateKronos](#):
>
> which was to make it available on Mac and Linux (Thank you, the manager is fantastic). Is there any information as to when?

The context is [here](https://github.com/JuliaLang/juliaup/issues/87) and [here](https://github.com/JuliaLang/juliaup/pull/89), 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.

---

<div class="post-metadata">

**Author:** ![davidanthoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/davidanthoff/32/223493_2.png) [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)\
**Post date:** [August 20, 2021, 5:15pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/10 "2021-08-20T17:15:42Z")

</div>

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 🙂 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](https://github.com/JuliaLang/juliaup/issues/10). 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.

> [@jling](#):
>
> self upgrade with some privileged permission

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.

---

<div class="post-metadata">

**Author:** ![Storopoli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/storopoli/32/209278_2.png) [@Storopoli](https://discourse.julialang.org/u/Storopoli)\
**Post date:** [August 20, 2021, 7:29pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/11 "2021-08-20T19:29:46Z")

</div>

> [@davidanthoff](#):
>
> 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.

That would be great!

---

<div class="post-metadata">

**Author:** ![banksiaboy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/banksiaboy/32/27032_2.png) [@banksiaboy](https://discourse.julialang.org/u/banksiaboy)\
**Post date:** [August 21, 2021, 1:27am UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/12 "2021-08-21T01:27:42Z")

</div>

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.

> **[jill](https://pypi.org/project/jill/)**
>
> JILL -- Julia Installer for Linux (MacOS, Windows and FreeBSD) -- Light

---

<div class="post-metadata">

**Author:** ![davidanthoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/davidanthoff/32/223493_2.png) [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)\
**Post date:** [August 21, 2021, 3:27am UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/13 "2021-08-21T03:27:39Z")

</div>

> [@banksiaboy](#):
>
> 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.

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).

---

<div class="post-metadata">

**Author:** ![SL6Trip](https://avatars.discourse-cdn.com/v4/letter/s/4da419/32.png) [@SL6Trip](https://discourse.julialang.org/u/SL6Trip)\
**Post date:** [August 21, 2021, 7:06am UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/14 "2021-08-21T07:06:59Z")

</div>

I’ll just like to mention [scoop](https://github.com/lukesampson/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?)

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [August 21, 2021, 1:49pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/15 "2021-08-21T13:49:39Z")

</div>

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

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

```

---

<div class="post-metadata">

**Author:** ![JohnnyChen94](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnnychen94/32/29979_2.png) [@JohnnyChen94](https://discourse.julialang.org/u/JohnnyChen94)\
**Post date:** [August 21, 2021, 2:49pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/16 "2021-08-21T14:49:09Z")

</div>

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

```julia
jill install

```

Not to mention that jill.py supports all platforms.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [August 21, 2021, 2:54pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/17 "2021-08-21T14:54:12Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![JohnnyChen94](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnnychen94/32/29979_2.png) [@JohnnyChen94](https://discourse.julialang.org/u/JohnnyChen94)\
**Post date:** [August 21, 2021, 3:47pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/18 "2021-08-21T15:47:35Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![davidanthoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/davidanthoff/32/223493_2.png) [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)\
**Post date:** [August 21, 2021, 4:05pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/19 "2021-08-21T16:05:23Z")

</div>

> [@SL6Trip](#):
>
> I’ll just like to mention [scoop](https://github.com/lukesampson/scoop) here (Windows only).

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.

> [@ufechner7](#):
>
> I am using Ubuntu on a lot of machines, and installing Julia (and keeping it up to date) is simple:

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](https://github.com/JuliaLang/juliaup/issues/84). 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.

---

<div class="post-metadata">

**Author:** ![ericphanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ericphanson/32/215186_2.png) [@ericphanson](https://discourse.julialang.org/u/ericphanson)\
**Post date:** [August 21, 2021, 4:14pm UTC](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721/20 "2021-08-21T16:14:50Z")

</div>

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/](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`.

[Next page](https://discourse.julialang.org/t/juliaup-for-for-mac-and-linux/66721.md?page=2)