This would be really useful for me if it had an auto-update mode, so I could replace Chocolatey. I added a Github issue requesting one.
Thanks to everyone who has downloaded this and is trying things out! The store stats at the moment show that we have 61 folks that downloaded this from the store, which is great.
Many of you made really useful suggestions how we could improve things, and those are also super helpful. We did not get a single real bug report, though, about things that just donât work. So now Iâm wondering whether there just arenât any serious problems? Does everything really just work?
I think the next decision weâll face is whether this would ready to be advertised on say the Julia homepage and be made more official in some form. Do those of you that have been using this feel it is more or less ready? Were there things that just didnât work? Are you using this with things like Jupyer/IJulia.jl integration and things work? Any feedback here that would help me make a decision whether this could be moved from a âhere is an experimentâ to âthis could be the default deployment story on Windowsâ would be fantastic.
10 Likes
I recently installed Julia from the Microsoft Store to update from 1.5 to 1.6. The only irritating thing for me was that it is just called âJuliaâ in the store without any mention of the Juliaup name.
After that, things have been smooth sailing. I was pleasantly surprised that my startup.jl was just recognized without any work on my part, even after uninstalling v1.5.
Managing Julia versions always used to be a chore, this makes it so much easier. Thanks David 
4 Likes
I had some feedback, but created issues at GitHub for it. Other than that, yhea, smooth sailing!
I think getting the colours straightend out would help first impressions:
This colour scheme does not strike me as professional or smooth. Change the background, and increase the resolution. But there is an issue for it at GitHub, so it will most likely get sorted.
So all in all, things have just worked out of the box. Tanks for the efforts!
2 Likes
I am publishing a new version to the store at the moment that is a pretty huge refactoring of a lot of things. For existing users everything will auto-update, but it might take a day or two until the submission shows up in the store, so be patient 
WARNING: This release will reset your juliaup configuration, i.e. all the Julia versions that you have installed with previous juliaup versions will be gone, and youâll start out with a âcleanâ install. I hope this doesnât cause too much trouble, essentially all youâll need to do is juliaup add <version> all the versions again that you were using so far. My plan is that this is the last time I do something like this, and going forward everything will be backwards compatible.
There are a number of changes to the existing AP, the most significant one that you now set the default via
juliaup default <VERSION>
rather than the previous juliaup setdefault <VERSION>.
There is also lots of new stuff! Here is a list:
- Lots of new channels:
-
release: always the latest stable, released version, this is the new default channel. -
lts: always the latest long term support version, currently 1.0.5. -
beta: if there is currently a beta for a new release, it will be that, otherwise the version fromrelease, so currently it is 1.7.0-beta.2. -
rc: if there is currently a release candidate for a new release, it will be that, otherwise the version fromrelease, so currently it is 1.6.1.
-
- Users always just select channels now, even things like
1.6.1are now considered a channel. This greatly unifies everything. - You can directly specify the channel you want to run when you start Julia by passing a first command line argument that starts with a plus and then the name of the channel. It must be the first argument! For example, if you have the
1.5channel installed, you can runjulia +1.5to start the latest Julia version in the 1.5. channel. If you have the beta channel installed, you can dojulia +betato run the latest beta etc. - You can link arbitrary commands as channels. This is especially useful for folks that compile from source. For example, you can link a source compile to a
devchannel with the commandjuliaup link dev C:\julia\bin\julia.exe. You can also use this to for example start something in WSL:juliaup link wsl wsl ~/julia/julia. Once you have linked something, you can use that channel as every other channel, i.e.julia +devworks or you can also make it the default withjuliaup default dev. - There is generic garbage collection in place now. For example, if you have the
1.6channel installed, then runjuliaup updateand this would switch out an older version from the1.6.xseries against a newer one, it will automatically delete the old version (unless that version is required by another channel). - There is a lot more error checking going on, with hopefully better error messages.
- The entire setup now updates the list of existing Julia versions independently from Windows Store updates. This will allow us to publish new versions much quicker, because we donât have to wait for our store submissions to go through. Should also make these updates much smaller.
I think the entire solution should be at a stage now where it is ready not just for brave early adopters but a much wider testing audience. While this is still not an official distribution and should still be considered a beta test or something like that, we have about 100 users, and it seems to work for everyone pretty flawlessly, so I think we can ramp up testing to a wider group. So, please, do try it out and report back any problems!
You can get to the Windows Store listing with this link or just search for Julia in the store. Feedback on the entire thing either here in this thread or over at GitHub - JuliaLang/juliaup: Julia installer and version multiplexer.
And if anyone wants to help out with the development of this, please join! Most of the code is actually written in Julia itself, so it should not be that difficult to contribute. One other major project would be to port all of this to Mac and Linux, so if anyone is interested in that, please also get in touch.
22 Likes
It should be in the Windows Store now and available for everyone, so please do give it a try!
8 Likes
Juliaup is great! Iâd like to rate it on the Microsoft Store but Iâm having trouble figuring out how to do that. I feel like I must be missing something simple. When I click on the stars nothing happens, is there a different place to leave feedback? Iâm on Windows 19043.1052. I read through this thread but there was no resolution.
1 Like
Ha, good question, I also just tried to rate it but didnât find a way to do that⌠But it must be possible somehow because we do have some reviews⌠Weird
2 Likes
The download from the Windows store https://www.microsoft.com/store/apps/9NJNWW8PVKMN is 230MB, Julia from https://julialang-s3.julialang.org/bin/winnt/x64/1.6/julia-1.6.1-win64.exe is 70MB. What is the difference?
Does the Github code
JuliaLang/juliaup: An experimental Julia version manager, currently only for Windows (github.com)
have the Juliaup app? Could not spot it looking in the repository.
juliaup is written in Julia and then compiled with PackageCompiler.jl and that binary version is shipped as part of the setup package. And PackageCompiler.jl does not exactly produce small outputs The uncompressed version of juliaup is about 320MB if one counts all the necessary files to run it. The original version of juliaup was written in C++ and just a few KB when compiled, but in the end I think it is much better to have it in Julia itself, the code is just so much easier. And hopefully at some point weâll have a binary compiler that produces binaries with a reasonable size. Might also be worth investigating whether one could shrink the size of current approach a bit, I havenât really looked into that.
I think another reason is that maybe the website download uses a more efficient compression than the store, but Iâm not sure about that.
On the flip side, updates of the app are much smaller: the store has some sort of smart delta compression story, so that a typical update of the entire app is more on the order of 20MB download for users.
Yes, see this file. This is the code for the julia launcher in the package, that one is written in C++ (because it needs to be super fast).
5 Likes
Thanks David for the details!
HOPEFULLY !!!
(I like to emphasize this missing feature wherever I can)
1 Like
I can also confirm that the referencing of the Julia binary from VSCode has changed with the Store version. I used to have Julia installed with the downloaded windows installer and enabled the âAdd Julia to PATHâ option. This in effected added a Julia entry to PATH and in VSCode I simply used julia as the executablePath.
With the Store version there is no Julia entry into PATH although calling $ julia in Powershell/Windows Terminal just works. So maybe there is a different way of registering the binary which does not use the PATH?
Additionally, getting the path to the Julia binary for the Store app is tricky, as right clicking it in the Start Menu no longer gives the option of opening the location of the shortcut and from there opening the referenced file. Truly the only option to get the path to Julia is by starting the Julia REPL and calling Sys.BINDIR.
Finally, just out of curiosity, knowing that Store apps are managed differently by the OS, what happens if one disables background execution?
2 Likes
The way this works is that Windows by default has the folder ~\AppData\Local\Microsoft\WindowsApps on the PATH. Windows Store (or rather MSIX) apps can declare âexecution aliasesâ, i.e. commands they want to have available on the PATH, and Windows then creates symbolic links in that WindowsApps folder for each execution alias that point to the correct binary in the actual install location. You can even manage each individual execution alias individually in the settings app, just search for âApp execution aliasesâ there. Overall this is a much more robust way to handle things: individual apps donât have to mess with the PATH, uninstall is clean, conflicts are properly handled by the system, and you donât even have to restart a shell after an install if a new execution alias was added to pick that up.
For Julia in particular there is the added benefit that we now have âoneâ julia on the PATH that is properly shared between multiple installed Julia versions (if they are all installed via juliaup).
Additionally, getting the path to the Julia binary for the Store app is tricky, as right clicking it in the Start Menu no longer gives the option of opening the location of the shortcut and from there opening the referenced file. Truly the only option to get the path to Julia is by starting the Julia REPL and calling
Sys.BINDIR.
So this is still a bit of a tricky design situation. I think ideally software would not rely on the actual location of the Julia binaries, but instead always start Julia via julia +channelname or just julia, so that the actual location becomes an implementation detail. But Iâm not sure that will work in all situations, so Iâm actually curios for what specific scenario you would like to know the path to the Julia binary?
One thing Iâm going to add very soon is a feature that you can call juliaup api v1 getinfo which then will return a JSON representation of all installed Julia versions with the corresponding commands to start them. My primary use-case for that at the moment is that the VS Code Julia extension can then use that information to reliably know which Julia versions exist on a given system, rather than the horribly hacky heuristics we use at the moment. Would something like that help in your situation as well?
We are not shipping as a UWP app, rather as a full trust, unvirtualized normal desktop app. So I think that something like a background execution toggle would not affect us at all.
7 Likes
@davidanthoff Thanks so much for the detailed answer!
Itâs for the only breaking issue I encountered when changing from the 3rd party/downloaded Julia installer to the store version: having executablePath in VSCode defined as simply julia worked with the installer version (with julia added to PATH by the installer) but stopped working with the store version. I had to set the executablePath to the actual path returned by Sys.BINDIR for VSCode to finally work. Is there any other way to do this (or whatâs the intended/recommended approach)?
Yeah, the idea is that you just leave the setting empty entirely and then it should work But Iâll have to look into that, I had assumed that your approach would also work.
2 Likes
I confirm that leaving the executablePath empty works! 
Also, I confirm that setting it to julia does not work.
Just another quick update: things should now work properly for users on 32 bit versions of Windows. In that case we now automatically download a 32 build of Julia, and we also have a 32 bit version of juliaup now. This entire thing should be entirely transparent to users, i.e. the Windows Store will just give you the correct build on whatever platform you are. Next up: making this work on Windows for ARM
6 Likes
I have just installed Juliaup for the first time from the Windows Store. It installs but when I call Julia it opens a window, waits a few seconds, and close it. If I try julia from the command line (Power Shell), it also hangs for a few seconds and gives me back the Power Shell prompt. It acts like julia is not there. The command juliaup works. What am I doing wrong?