# Plans for Updating Julia

**URL:** <https://discourse.julialang.org/t/plans-for-updating-julia/75880>\
**Category:** Tooling\
**Tags:** installation, update, juliaup\
**Created:** [February 5, 2022, 11:29pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880 "2022-02-05T23:29:40Z")\
**Posts on this page:** 20\
**Page:** 2

<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:** [February 7, 2022, 11:21am UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/21 "2022-02-07T11:21:55Z")

</div>

> [@tt1234567](#):
>
> don’t really like the Windows Store.

I really like winget, which means I don’t have to struggle with the Store anymore.

---

<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:** [February 7, 2022, 11:25am UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/22 "2022-02-07T11:25:52Z")

</div>

> [@oheil](#):
>
> But whenever I want to experiment with something I install a second Julia from the windows installer

You can switch between Julia versions with Juliaup too.

> [@oheil](#):
>
> (no PATH e.g.) … (without any integration).

I’m not sure what this means.

---

<div class="post-metadata">

**Author:** ![oheil](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oheil/32/220745_2.png) [@oheil](https://discourse.julialang.org/u/oheil)\
**Post date:** [February 7, 2022, 11:47am UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/23 "2022-02-07T11:47:40Z")

</div>

> [@DNF](#):
>
> You can switch between Julia versions with Juliaup too.

I know.

> [@DNF](#):
>
> I’m not sure what this means.

I mean, I don’t want any integration into my OS, like setting PATH variables or whatever is needed.

So, for me, despite knowing about juliaup’s features, I like to have a single juliaup version installed (which I can run with `julia` without setting the PATH variable, because it’s using a specific windows folder) and several other Julia versions which are just some folders somewhere without the OS bothering about it (except for deinstalling using windows app configuration).

Perhaps it’s just something about the “feeling of control”, but whatever it is, I prefer things I like, instead of things, I don’t like. Being rational into extremes isn’t rational.

---

<div class="post-metadata">

**Author:** ![jlapeyre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlapeyre/32/4514_2.png) [@jlapeyre](https://discourse.julialang.org/u/jlapeyre)\
**Post date:** [February 7, 2022, 9:13pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/24 "2022-02-07T21:13:09Z")

</div>

To clarify a bit: I knew of, but only alluded to, the implementation language history of juliaup. rust is clearly the winner there, especially since the (volunteer) developers are very enthusiastic about the choice. There may be some people who think that a standard installer should be written in Python. Just to avoid sowing doubt among people who haven’t looked into this: I am not one of those. Especially after what has come out in this topic, I am 100% behind the current implementation of juliaup in rust.

To reiterate, there was still some confusion here between jill.py and the shell-script jill. They are essentially unrelated, sharing only a name. jill.py is much more capable.

> [@Lilith](#):
>
> Juliaup is an order of magnitude larger than it needs to be

The LOC in jill.py and juliaup are comparable. jill.py might even have more if it was brought up to feature parity. (The fast multiplexer is impossible)

I agree strongly that the multiplexer feature requires a very fast executable if `julia` is linked to the `julialauncher`. But, I think having the option to simply organize and check versions and download and install, rather than launch, is useful. E.g. I want my daily driver to load a custom system image, and maybe I want it to be called `julia`. As far as I can tell, simply deleting the `julia` symlink (in linux) to julialauncher is enough to get this. I imagine custom system images, etc. might be added later to juliaup.

> [@davidanthoff](#):
>
> end-users don’t need Rust or anything related to Rust installed on their system to use Juliaup.

Apropos, it was mentioned that “rust?” should be removed as a dependency in the matrix in the original post. This is a crucial point in understanding the choices.

> [@DNF](#):
>
> Apple will no longer bundle python (2 _or_ 3) with MacOS

Ok. That’s a big deal, and makes Python somewhat less attractive even as an alternative.

> [@oheil](#):
>
> My main hope in using Julia is: **no R and no Python anymore**.

That is also my fervent hope. But, R is irrelevant here. And using Python to install Julia is only tangentially related to Julia competing with Python. The only reason I am interested in installing Julia from Python is to make it easier to integrate Julia into Python projects. It’s to promote Julia, not Python. At the moment, I have to use jill.py and it works well. But, maybe it can be replaced by juliaup in the future.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [February 7, 2022, 11:21pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/25 "2022-02-07T23:21:44Z")

</div>

BTW: I find the experience with **portable** Julia superior to the alternative (installer)! Especially in combination with a custom depot. See [Portable Julia - #16 by PetrKryslUCSD](https://discourse.julialang.org/t/portable-julia/45339/16)  
Edit: try it with Julia 1.7.1.

---

<div class="post-metadata">

**Author:** ![Lilith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lilith/32/27492_2.png) [@Lilith](https://discourse.julialang.org/u/Lilith)\
**Post date:** [February 8, 2022, 3:33pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/26 "2022-02-08T15:33:28Z")

</div>

@carstenbauer Thanks! I’ve removed “rust?” pardon my ignorance that rust compiles to standalone executables.

According to the juliaup [readme](https://github.com/JuliaLang/juliaup), “On all platforms it is recommended that you first uninstall any previous Julia versions and undo any modifications you might have made to put `Julia` on the `PATH` before you install Julia with the installer in this repository.” I’ve opened [an issue](https://github.com/JuliaLang/juliaup/issues/244) requesting that the behavior you utilize be officially supported, but until then, I think it is appropriate to leave a no in that row.

---

<div class="post-metadata">

**Author:** ![Lilith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lilith/32/27492_2.png) [@Lilith](https://discourse.julialang.org/u/Lilith)\
**Post date:** [February 8, 2022, 3:40pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/27 "2022-02-08T15:40:57Z")

</div>

Perhaps this is a silly question, but are we reinventing the wheel by writing our own multiplexer in rust instead of using the operating system’s default behavior via symlinks and path environment variables?

For example, on my machine I have julia-1.6.4, julia-1.6.5, julia-1.7.1, julia-1.7.2, etc. and have julia symlinked to julia-1.7.2, julia-1.7 symlinked to 1.7.2, 1.6 symlinked to 1.6.5, etc. I can easily change my default julia with `ln`, as well as configure my ide to run a specific version regardless of the systemwide defaults.

---

<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:** [February 8, 2022, 3:50pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/28 "2022-02-08T15:50:35Z")

</div>

> [@Lilith](#):
>
> with `ln` ,

stop thinking in Linux, although I only use Linux, but if you want Julia to be universally accessible reinventing some wheels is no big deal, it’s not like we’re going to pile on top of `juliaup` and having breaking release every month, it’s just an end users’ tool, the less assumption we make (by reinventing the wheel), the more control we have over the system that we can ensure it works on all platforms

---

<div class="post-metadata">

**Author:** ![jlapeyre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlapeyre/32/4514_2.png) [@jlapeyre](https://discourse.julialang.org/u/jlapeyre)\
**Post date:** [February 8, 2022, 5:20pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/29 "2022-02-08T17:20:34Z")

</div>

- Not a silly question. But, I think symlinks and environment variables are kind of a mess to work with. People (eg linux distros) tend to write utils with APIs to manage them. And the multiplexer is already written. Having a single API is great for help/documentation/cognitive load. Otherwise each platform must have it’s own recipe. And nothing precludes you from ignoring the launcher and rolling your own system.

- I think “recommended that you first uninstall” is to avoid problems for the uninitiated. I found that you can easily delete a link, and edit your PATH and get what you want. So in a practical sense, it already plays with other installations. I haven’t really used juliaup, rather only used it while testing different installation methods. So far, updates and queries have not silently clobbered my modifications.

---

<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:** [February 9, 2022, 3:45am UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/30 "2022-02-09T03:45:49Z")

</div>

> [@jlapeyre](#):
>
> I think “recommended that you first uninstall” is to avoid problems for the uninitiated.

Yes, that is correct. I just don’t want to deal with support requests when folks end up having two `julia` things on their `PATH` 🙂 But as long as someone sorts that out properly, it should all just work fine.

---

<div class="post-metadata">

**Author:** ![phlavenk](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/phlavenk/32/1873_2.png) [@phlavenk](https://discourse.julialang.org/u/phlavenk)\
**Post date:** [February 9, 2022, 8:42am UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/31 "2022-02-09T08:42:04Z")

</div>

I don’t think the dispatcher `julia` from juliaup is identical to using symlinks. There might be a super useful feature in the near future where, if the project is known at startup time, you can dispatch to the appropriate (compatible) julia version. This is from my point of view a killer feature that you just cannot mimic with symlinks.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [February 9, 2022, 1:49pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/32 "2022-02-09T13:49:18Z")

</div>

Might make sense to have an “Advanced installation” section that explains what someone who is comfortable with more manual stuff can do.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [February 9, 2022, 1:59pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/33 "2022-02-09T13:59:27Z")

</div>

> [@jlapeyre](#):
>
> I wonder how often Julia is installed in a python-less system. Python has big advantages over rust. It is always installed on linux and macos. It can easily be installed on windows. But, admittedly, that’s (perhaps) not as easy as just going to the windows store.

It’s not easy to get a good Python distribution through the windows store. It’s so hard these days that most people just use WSL. WSL is essentially the answer to how much Python does not work on Windows. Python on Windows is very fundamentally broken in many ways that it just does not seem like a good idea to keep going that direction.

---

<div class="post-metadata">

**Author:** ![jlapeyre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlapeyre/32/4514_2.png) [@jlapeyre](https://discourse.julialang.org/u/jlapeyre)\
**Post date:** [February 9, 2022, 2:46pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/34 "2022-02-09T14:46:30Z")

</div>

> [@ChrisRackauckas](#):
>
> It’s not easy to get a good Python distribution through the windows store.

Just to be clear, by “not as easy as just going to the windows store” I meant that installing juliaup from the windows store might be easier than installing Python and then jill.py. I’m surprised to learn that it’s worse than I thought, that Python is so hard to install on windows. I just saw that [even Microsost](https://docs.microsoft.com/en-us/windows/python/web-frameworks) recommends Python on WSL as the preferred method! This is a long way from the old days, when they dismissed Linux as an unsecure, buggy, communist plot (for real). I guess that conditioning on a user wanting to install Julia increases the probability that the user already has Python installed. Notwithstanding, I’m hearing that the answer to “how often Julia is installed in a python-less system” is “likely pretty often”. In any case, I think exploring calling out to juliaup (as it improves) from Python tools such as `find_julia` is a good idea.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [February 9, 2022, 3:08pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/35 "2022-02-09T15:08:22Z")

</div>

> [@jlapeyre](#):
>
> I just saw that [even Microsost](https://docs.microsoft.com/en-us/windows/python/web-frameworks) recommends Python on WSL as the preferred method! This is a long way from the old days, when they dismissed Linux as an unsecure, buggy, communist plot (for real).

I’m convinced that WSL only exists because Python got popular and works so poorly on Windows.

---

<div class="post-metadata">

**Author:** ![oheil](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oheil/32/220745_2.png) [@oheil](https://discourse.julialang.org/u/oheil)\
**Post date:** [February 9, 2022, 3:18pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/36 "2022-02-09T15:18:15Z")

</div>

Regarding the table in the OP, I would like to suggest, to remove “known bugs” and “(with bugs)” in the juliaup column (only column where it occurs).  
This emphasizing seems to imply that the other alternatives don’t have bugs, which I doubt. (without research, just as a general doubt).  
And even the fact, that juliaup does have known bugs, isn’t anything which is of special interest in this case, when asking for experience on the different alternatives.

The whole python thing here is also derailing the discussion. As already said:

> [@jlapeyre](#):
>
> R is irrelevant here

and so is python. Just because there is something written in python doesn’t make python relevant in the question of version managers for julia in a general sense.

For me, to answer the OP: I don’t have any need for a version manager for julia. juliaup is the only convenience tool I have used so far, and I don’t need it, but I understand that it makes it easier for some people. Important for me is, that I always have a source, from where I can install on my own on any OS on my own full control without any OS integration. This is quite the opposite from a version manager, it’s more like: can I skip any version manager. If not, that’s a problem.

> [@PetrKryslUCSD](#):
>
> **portable** Julia

is the gold standard for me (but I don’t use it as I am happy enough with the windows installer from the official julialang web site).

---

<div class="post-metadata">

**Author:** ![sylvaticus](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaticus/32/203883_2.png) [@sylvaticus](https://discourse.julialang.org/u/sylvaticus)\
**Post date:** [February 9, 2022, 8:59pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/37 "2022-02-09T20:59:36Z")

</div>

Can you have with `juliaup` several versions at the same time so that on one terminal you are using, say, `julia1.0`, and in another `julia1.7`? (that’s what I am using with symlinks)

---

<div class="post-metadata">

**Author:** ![tbeason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tbeason/32/15898_2.png) [@tbeason](https://discourse.julialang.org/u/tbeason)\
**Post date:** [February 9, 2022, 9:04pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/38 "2022-02-09T21:04:46Z")

</div>

Yes. The different versions are called “channels”. I think many people in this thread have a misunderstanding of how `juliaup` works, so I’m going to post the link again

> **[GitHub - JuliaLang/juliaup: Julia installer and version multiplexer](https://github.com/JuliaLang/juliaup)**
>
> Julia installer and version multiplexer. Contribute to JuliaLang/juliaup development by creating an account on GitHub.

---

<div class="post-metadata">

**Author:** ![carstenbauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/carstenbauer/32/4981_2.png) [@carstenbauer](https://discourse.julialang.org/u/carstenbauer)\
**Post date:** [February 9, 2022, 9:13pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/39 "2022-02-09T21:13:38Z")

</div>

And just to be explicit here, you can also have different symlinks for different channels (i.e. versions), yes.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [February 10, 2022, 1:44pm UTC](https://discourse.julialang.org/t/plans-for-updating-julia/75880/40 "2022-02-10T13:44:16Z")

</div>

5 posts were split to a new topic: [Python on Windows](https://discourse.julialang.org/t/python-on-windows/76161)

[Previous page](https://discourse.julialang.org/t/plans-for-updating-julia/75880.md?page=1)

[Next page](https://discourse.julialang.org/t/plans-for-updating-julia/75880.md?page=3)