Yes, that is correct, if you use the Juliaup story you’ll only have one entry in the list of installed programs and can uninstall all the other Julia versions you might have on your system. One caveat: at the moment Juliaup only supports Julia 1.5.1 and newer, so if you have older versions installed you might want to hold on to them a little bit longer. I’m working on fixing this right now, pretty confident that we’ll have support for every Julia version since probably 0.7 in Juliaup in a few days.
6 Likes
I should mention one other caveat: if you uninstall Juliaup, it won’t uninstall the Julia versions that you installed using juliaup, i.e. all of those Julia versions will stay around in ~/.julia/juliaup! In a way this is now similar to the situation with packages and artifacts that you install using Julia: those are also not removed when you uninstall Julia from your system.
I’m not super happy about that aspect of things, but a) it is not clear to me right now how I could fix this easily and b) it seems in line with packages and artifacts, so I think at the moment the general rule just is that to really get rid of Julia on your system you need to uninstall it and delete your .julia folder.
4 Likes
I’d be really happy if juliaup provided a command to set the package server to use (i.e. environment variable JULIA_PKG_SERVER).
1 Like
Btw. please rate Juliaup at the Microsoft Store
6 Likes
Wow, this is definitely going to get more people into Julia.
1 Like
I think the issue with needing git raised by @ufechner7 is a valid one. This was the reason I included a portable git in my portable julia.
1 Like
This looks like an interesting initiative!
I typically get pretty annoyed when a windows program’s uninstall routine leaves files behind, which seems like a quality smell for me.
What’s the reason behind the workaround with the hardlinks to .julia? Why don’t you put everything into AppData/Local/ and /Roaming as appropriate, which seems the canonical/proper way to do this on windows? (E.g. my python installation with all environments, except one or two config files, lives in AppData/Local/ mambaforge, VSCode afaict similarly)
1 Like
Fwiw, I agree with not bundling git. When i need git, I want to separately install it myself, however I prefer. Or did I misunderstand and git is a dependency needed for juliaup to function?
1 Like
I should say that I completely agree that it would be great to have an easy way to get a system into a state where lots of useful tools are installed, I just don’t think that the core/base installer for something like Julia (which I hope Juliaup will become) is the right tool for that.
I think at least for Windows this would ideally be solved at the winget level. If winget had support for packages with package dependencies we could publish a package SuperJulia that had a dependency on say Julia, git, VS Code and maybe other stuff. winget install SuperJulia would then install all those individual pieces in one go, as if someone had installed them individually. My understanding is that package dependencies are planned for winget 1.1, see here.
3 Likes
This is a bit of a longer story 
I completely agree with your sentiment, that was where I started as well, but there are some constraints that make this tricky.
The core setup tech that the Windows Store uses is MSIX, so everything we can do is dictated by the capabilities of that. A MSIX in its simplest form can have a payload of files that get installed onto a user system. Those “normal” files end up in a filesystem location that is completely managed by MSIX, mostly inaccessible from normal user accounts etc. In particular, these files are not installed into APPDATA locations, instead they are actually installed into a shared system location so that if two user accounts install the same app, the installed stuff is automatically shared between user accounts. One can declare various “entry” points in an MSIX installer that then surface these files to users, for example startmenu shortcuts, and execution aliases, which essentially put things onto the PATH via the symlink approach that @oheil described and some other options. The stuff that gets deployed in this way is completely read-only. For juliaup, I essentially distribute three things via this standard MSIX approach: 1) a small julia.exe wrapper that ends up on the PATH and then launches the “real” julia.exe, 2) juliaup.exe and one full default Julia distribution. At uninstall, everything that was included in this way in the MSIX installer is removed, of course.
By default all MSIX installed software runs in a lightweight container that completely virtualizes the registry and everything in APPDATA. That whole system is powerful, but ultimately not helpful for Julia. In essence, if a MSIX software writes some files into a APPDATA location, those file will only be visible to that specific app, no other app can even see these files. Same with registry keys. The benefits are then that at uninstall the MSIX installer can very cleanly uninstall everything that the app might have ever created in any APPDATA folder. So in theory juliaup could install Julia into APPDATA locations, and then at uninstall that would all be removed. The problem is that we really need the ability to write files into APPDATA locations that are visible to software that runs outside of the Julia container: the main culprit is Jupyter. We need the ability to write kernel spec files for Julia that Jupyter can see, otherwise the entire Jupyter integration for Julia would be broken. The only way around this that I could find was to completely disable the APPDATA file virtualization/container story for the Juliaup MSIX installer, and that is what we are shipping now. So the Julia MSIX is not using the virtualization for APPDATA or the registry. The upside is that modifications from Julia code in APPDATA or the registry are visible to other software, the downside is that those changes are no longer removed at uninstall.
So now that we are in a world where nothing in APPDATA is removed at uninstall, I felt it would be better to install the Julia versions into .julia/juliaup rather than somewhere in APPDATA where they would really be easily forgotten. The story now with Julia is essentially that when you uninstall Julia via the uninstaller, it will leave lots of stuff behind in ~./julia: packages, artifacts, and now a little bit more in the form of Julia installs. If you want to get rid of all of that, you can just delete the .julia folder. While I don’t think this is ideal, I also feel it doesn’t really make the currently existing situation worse 
.
What we would really need is the following: an ability to configure our MSIX installer such that it cleans up one known folder in APPDATA at uninstall. But as far as I can tell that isn’t possible at the moment.
8 Likes
Alright, did a bit more digging whether we could somehow remove more stuff at uninstall, I’m tracking those ideas here.
2 Likes
Is it possible to add the appbundle to the GitHub release page like winget does? (Or just point me to a direct download link?)
I’d be keen to try it but for some reason I can’t install it from the store directly, though I can install downloaded appbundles and get updates for them (I’m pretty sure it’s something broken on my laptop since I can’t install anything else via the store either).
Yeah, I’m trying to get the CI story up and running, and agreed, it would make sense that it just publishes the .appxbundle files as part of the release tag on GitHub for every tag.
We will have to sign those .appxbundles, but I think that shouldn’t be too complicated either. And I’m not super positive how easy it would be to install them directly: we are requesting lots of restricted permissions for our MSIX installer. We got those permissions when the thing is installed via the store, but it is a bit unclear to me whether that works equally well if one installs the appxbundle directly. Might just work, or not
3 Likes
One more quick update: I now listed the store submission, so you no longer need the direct link to find Julia in the Windows Store. Instead, you can just search for Julia in the Windows Store and find the app that way.
7 Likes
Oh my, what a messy situation, I don’t envy you! 
Thanks for the detailed reply!
Out of interest, does this all work without admin rights (e.g. on locked-down machines)?
I guess not the only one, don’t any IDEs that e.g. have to detect the presence/location of Julia need to be able to see those folders? Or does that work by just probing for the julia executable?
1 Like
The Julia installer may not be the right tool for the job, agreed.
Yes, everything should work without admin rights.
I know the VS Code extension best, and for that the exposed julia execution alias is enough, so for that the container would not have been a problem. But for Jupyter the package IJulia.jl actually writes into a shared location that the Jupyter binary then reads from, and that won’t work with the container. But I think even beyond that, a container is just not a good abstraction for a programming language: after all julia.exe is primarily used to run user code, and that just shouldn’t run inside a Julia specific container.
4 Likes
A report. I usually install Julia using the Chocolatey package manager. I uninstalled Julia 1.6.1
I had an older version 1.5.3 on my system - which does not uninstall using the Windows Control Panel.
I used the Microsoft Store to install Julia…
First time it starts up Julia 1.5.3 with this warning:
The latest version of Julia in the 1 channel is Julia 1.6.1. You currently have Julia 1.5.3 installed. Run:
juliaup update
to install Julia 1.6.1 and update your current channel to that version.
NOTE: please tell the user how to run juliaup It might be obvious that this should be run in Powershell but maybe ‘Open Powershell and run juliaup update’
The Start Menu now offers me Julia (app) which starts version 1.161
and Julia 1.5.3
I guess I will have to nuke my .julia directory to get rid of 1.5.3 - I really would not expect the juliaup installer to manage this.
Also as an aside the blue background on the Julia three balls logo which Juliaup installs is really not good for me. I am colourblind and the three balls disappear. Please use a clear background?
1 Like
Yes, agreed, see here.
You can use juliaup remove 1.5.3 to uninstall it. But in general we could probably do a lot more to have some automation about removing unnecessary Julia versions, see here.
Yeah, the whole artwork is a mess right now I added your concern to the issue that is tracking that here.
Thanks for the feedback, very useful!
5 Likes
Sorry, I got carried away and simply burted out input as comments. I then realized that they are better off as github-issues, and so I gave my input as github issues instead.
Thanks a lot for the great work in making julia more accessable to less technical users. Not even MatLab can boast an installation this simple! 5 stars given in the microsoft store <3