[ANN] Juliaup Preview - Julia version manager and Windows Store installer

Yes, exactly! And that whole part is actually handled by the MSIX installer engine that ships with Windows 10, the way we hook into this is that we just declare that we want something to appear on the path in this line in the setup program.

3 Likes

Haha, fair point, although it was true as well for regular Juno without JuliaPro, which I guess is what most people use in practice. I guess I wanted to point out that a significant part of the Julia userbase is used to (or has unknowingly accepted) the fact that the “official” Julia IDE runs on multiple threads by default.

Oh, sorry, I completely missed the context of your comment, I was thinking that you were talking about something entirely different (namely bundling a lot of software together) :slight_smile:

Oh OK, thanks for the clarification @oheil! I was actually looking for “julia” somewhere in the path so completely missed that… And you were right @davidanthoff, it was indeed a path I had entered manually (which I assumed would be gone when I uninstalled the extension). Everything works like a charm now, thanks!!

3 Likes

Is there a way to include git bash in this kind of setup? Julia without git would not help me.

1 Like

I don’t think I want Juliaup to go in the direction of bundling more stuff, in my view it should really just be for Julia and nothing else. Maybe other tools that bundle more things could sit on top of it, not sure…

But I think with the release of winget the entire situation should just get a lot easier, I’m pretty sure winget install git should be enough to get git installed on Windows already. And then once we think that Juliaup is stable, winget install julia would be enough to get this Juliaup/Julia story installed.

6 Likes

With Juliaup there is now only one single big Julia app in Win10 showing in the list of installed programs, with possibly many versions encapsulated inside it.
In snapshot below, Julia 1.6.1 was the legacy installation, while Juliaup’s installed “Julia” containing in this case 2 versions after updating:

Assume that hobby Julia users can safely remove the different installations of Julia and work from now on with Juliaup only?

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.:parasol_on_ground:

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 :wink: 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 :slight_smile:.

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