There is a bug in the currently shipping version of AppInstaller that means any update to the package will only be installed after a system restart... MS is aware of this bug and as far as I can tell trying to fix this, but it is unclear to me how fast a bug fix would ship broadly across Windows versions.

The easiest way around this would be to go to a Windows Store submission right away: it doesn't use AppInstaller, so that problem would just not be there.

We need to get high-quality assets (images etc) both for the MSIX installer and the store listing.

At the moment we only support juliaup update to update the current default channel. It would be nice if one could also do juliaup update <channelname> to update some other channels. This is now implemented.

We could also support juliaup update --all to update all channels. That would require us to keep a list of "installed" channels, though, which is a concept we don't have at the moment.

At the moment everything is hard coded to store Julia versions in ~/.julia/juliaup. We should change that to check whether JULIA_DEPOT_PATH is configured and then use the value there if present.

Currently it shows things in a weird format, we should make it display things in the same what that one would specify things in setdefault. That requires in particular a change in how we display x86.

This suggestion comes from here.

I think one option would be that if juliaup update detects an update that increases the minor version of Julia, that it copies the older environment file to the new Julia minor version. I think I would limit it to this scenario, i.e. not do anything with downgrades or stuff like that.

One question is whether just copying the env is actually a good user experience? Or would we have to instantiate, build or do other things as well?

I'm thinking Azure pipelines with approvals for specific environments, similar to what we have for the VS Code extension.

Maybe one could actually make something like sudo apt install julia install a packaged version of the launcher from this repo here and juliaup...

One thing that a user might stumble on is how to run juliaup commands without having to launch a new command window. They may not realize shell commands can by run from within Julia.

So something like (paraphrased message):

Julia version 1.6.1 is available. Run:

  juliaup update

to install Julia 1, the latest Julia version for the current channel.

This command may be run within Julia by typing a semicolon (;) to access the shell prompt.

In playing a more naive user, I did the following when the program first lanuched:

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.
┌ Warning: Expected non-existent C:\Users\densb\AppData\Local\Programs\Julia 1.5.3\share\julia to be your Julia directory.
│ Certain functionality will be disabled.
│ To fix this, try deleting Revise's cache files in ~/.julia/compiled/v1.5/Revise, then restart Julia and load Revise.
│ If this doesn't fix the problem, please report an issue at https://github.com/timholy/Revise.jl/issues.
└ @ Revise C:\Users\densb\.julia\packages\Revise\VxkZO\src\packagedef.jl:1311
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.5.3 (2020-11-09)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> juliaup update
ERROR: syntax: extra token "update" after end of expression
Stacktrace:
 [1] top-level scope at none:1

The message should be more clear on the fact that this command should be put into the run window, or directly into a command prompt. I imagine that the uses who install julia with the app store will be the least technically savvy, so I think this is needed.

The file path shown in the title of the window is not what we want to expose to the user:

Right now one can only configure a default Julia version via juliaup setdefault 1.4.2. It would be nice if one could also start a specific Julia version without changing the default configuration.

One option might be julia --version=1.4.2, i.e. we would "overload" the --version command line argument so that if one specifies a version, it will start that specific version.

I'm mixing lots of different styles, nothings is structured very well, lots of code duplication etc. It all works, but it is a bit of a mess...

This is probably a bit speculative at this point, but it would be fairly simply to look at a Project.toml/Manifest.toml if one is specified via the --project command line arguments and see whether these specify a specific Julia version. If they do, run things in that specific version.

Of course, right now there is no official way to specify a Julia version in a Manifest.toml. For Project.toml, the situation is a bit different: at least for packages one can specify a version in the compat section. The mybinder integration for example looks for a julia entry in the compat section to decide what Julia version to use. We could do something similar, for example if there was an entry julia = "=1.3.1" in the Project.toml, we could start Julia 1.3.1.

But maybe this should also just wait until there is an official way to record Julia versions in Manifest.toml files.

The new platform separator is now ~, so one would say things like juliaup add 1.6.1~x86. This almost certainly is not implemented throughout yet.

At the moment we only have numbered channels, like 1 and 1.6. We could add additional channels latest, lts and nightly (maybe).

The idea would be that if one is on a 64 bit system, 1.4.2 points to the 64 bit version, and 1.4.2-x86 to the 32 bit version. On a 32 bit system 1.4.2 would point to the 32 bit version.

So in general, a version or channel name without a platform specifier refers to the platform that one is running on, and then there are other variants that one can also install that have a platform specifier added.

The installer always bundles one Julia version, and we should special case installation of that version to not download anything, and instead just copy the bundled version over to .julia/juliaup.

The Julia app is installed into the folder C:\Program Files\WindowsApps\Julia-1.4.2_1.0.0.0_x64__m018azp39xxy8 by the MSIX engine, and so Sys.BINDIR returns C:\Program Files\WindowsApps\Julia-1.4.2_1.0.0.0_x64__m018azp39xxy8\Julia\bin. That folder, though, is inaccessible to any application other than Julia itself (or rather any other binary that is not part of the Julia MSIX installer). So if from within Julia one tries to start C:\Program Files\WindowsApps\Julia-1.4.2_1.0.0.0_x64__m018azp39xxy8\Julia\bin\julia.exe it works, but if I try to run that from say a shell or some third party application, it won't work.

One example of a program where this leads to a problem right now is the VS Code extension (*).

The MSIX installer also adds a symbolic link (I think) for julia.exe to ~\AppData\Local\Microsoft\WindowsApps, and that is the path one should use to start Julia from outside Julia itself, say from VS Code.

I think fixing this might require some fiddling, but it doesn't look impossible to me.

(*) I do have a fix for the VS Code extension that is simply and easy, just can't merge it right now because we are in feature freeze for Juliacon for the extension.

We could also add a GUI application named Juliaup or Julia Configuration or something like that. This would appear in the Start menu and would show a list of all channels on the system, which ones are out-of-date, with a button to update individual or all channels.

Perhaps a github action that checks probes the list and updates the manifests if there is a change (especially relevant for the nighlites)

At the moment we can't configure the update behavior of individual channels. Instead, whenever a channel is outdated, it will show a reminder to update the channel.

Instead, we might want to add configuration per channel, a la auto (automatically update the channel), prompt (prompt for updating a channel when there is a new version), remind (just remind that there is an update, without UI to update, that is what we have at the moment) and never (just don't bug a user with any update info).

The current version breaks IJulia. The reason is this: any app installed with an MSIX installer runs in a container, and in that container %APPDATA% and the registry is virtualized away, so that these become per-app state that is not shared with any other app (the situation is slightly more nuanced than this, but for our case this is an accurate enough description. See here for the full description). When IJulia.jl writes the kernel information into %APPDATA%\jupyter it succeeds, but those files are not visible to any other application than Julia itself. In particular, these files are not visible to Jupyter or Python, and then nothing works.

I've picked IJulia.jl as the example here, but this might be a problem for other packages as well: if they write state into %APPDATA% and then rely on other applications to read that state, things won't work.

I consider the IJulia.jl case a showstopper: we obviously need to find some solution to that before we can even consider going forward with the MSIX installer.

Right now I can think of two solutions:

1. We convince the Jupyter project to use different file system locations for configuration files (jupyter/jupyter_client#544). I think that would in general be a good idea, because the Windows Store distributed version of Python seems to be running into similar issues, and any other kernel that wants to ship via the Windows Store would also face the same problem. I think medium to long term, %APPDATA% just doesn't seem to be a great place to share cross-application configuration. Having said that, any such change would take a long time to make its way through the Jupyter ecosystem, so I'm not really convinced this would allow us to use an MSIX installer anytime soon.
2. We try to convince MS to give us unvirtualizedResources capabilities for a potential Windows Store submission. This would solve the problem entirely: it would just switch off the virtualization of the %APPDATA% folder for Julia, problem solved. I'm fairly optimistic that this might work: Python has that capability for its Windows Store submission as well, and in general we seem to have a good reason for asking for it. This would also solve any problems that other packages might have around %APPDATA% configuration settings. This strategy will not work for any pre Store AppInstaller based solutions, as far as I can tell there is no way to install a MSIX package via AppInstaller with that capability.

Generally it would be nice if juliaup tried slightly more aggressively to uninstall/delete old Julia versions. Some ideas:

1. juliaup update could remove the old Julia version after the update, if that old version is not used by any other channel that the user has used and was not explicitly installed. This would require us to track more information about the reasons why a given Julia version is present on a user system in juliaup.toml.
2. We could add a garbage collect feature to juliaup that has some heuristic for deleting old Julia versions.

Something broke. I had the first release from the store that you posted on Slack, then just updated it with your new post, and now it won't launch. A console window very briefly flashes up then disappears.

I had the previous one running while updating.

The message on starting julia after getting it from the store is

The latest version of Julia in the 1 channel is Julia 1.6.1

The channel name should probably be changed to release or something like that?

This is currently blocked by JuliaLang/PackageCompiler.jl#511.

Right now this only supports Julia 1.4.x. We should add support for all previous Julia versions.

I tried this already but ran into some problems, in particular I was not able to compile any Julia version pre 1.4.0 on my build machine.

The order of thing:

• I had julia installed, and the bin/julia.exe manually typed into the settings for the julia extension for VSCode
• I uninstalled julia with chocolatey, but kept my .julia folder
• I checked that julia was removed from path - it was
• I installed julia via the microsoft store - worked great
• Checked that julia was in my path - it was
• I updated to 1.6.1 with juliaup update from a terminal
• I opened up a .jl script in VSCode

At this point I am notified that VSCode has actually NOT updated the location of the julia.exe. I was able to find it in C:\Users\densb\AppData\Local\Microsoft\WindowsApps\JuliaComputingInc.Julia_b0ra4bp6jsp6c, and manually type that is as the location of the excecutable in the settings for the julia extension for VSCode.

This was suppoed to be automated, right?

We should test whether this installer can easily be used from Github Actions, Travis, AppVeyor etc.

The extracted files from the Julia archive should just inherit permissions, but Tar.jl changes all the permissions on all the files.

Should we use that? Might make the code a bit cleaner...

Installing Julia 1.6.1.
ERROR: IOError: mkdir("C:\\Users\\nicho\\.julia\\juliaup\\x64\\julia-1.6.1"; mode=0o777): no such file or directory (ENOENT)

I think you want mkpath ?

We can probably use the native UWP download API, but still need some way to unzip or untar the archives we are going to download.

I deleted all files in juliaup, then from the command prompt, then ran julia.

No Julia version for channel 1 is installed on this system. Run:

  juliaup update

to install Julia 1, the latest Julia version for the current channel.

Windows console windows are closed as soon as their program exits. I suggest adding a "press any key to exit" read prompt to ensure the window stays open so the message can be read.

Originally posted by @BioTurboNick in #36 (comment)

The command should minimally display the currently active default.

Should we? Not sure, because Windows Terminal for example has pretty nice new default fonts. But we should investigate. I think technically this might actually be fairly simple because MSIX does support font install, AFAIK.

If we could get the customInstallActions permission for our store submission, we could use this to remove arbitrary stuff at uninstall, for example all the Julia versions that were installed with juliaup.

In my mind this would make most sense as part of a more generic redesign of storage locations. At the moment, a Julia depot is really a mix of stuff that in an ideal world would automatically be uninstalled when Julia is uninstalled, and stuff that should stay around even after Julia is uninstalled. In particular, it seems to me that in an ideal world, the following things would all be uninstalled with Julia itself: ~/.julia/packages, ~/.julia/compiled, ~/.julia/registries (at least if they are really, truly read-only cache copies from a server), ~/.julia/artifacts and ~/.julia/juliaup. I think ideally all those things would actually no longer be stored in ~/.julia, but instead in say %APPDATA%/Julia, and then that folder gets removed at uninstall. The principle then would be that everything in ~/.julia stays around at uninstall, but we have a new location for files that get removed when Julia is uninstalled. At some level this would be a split of the Julia depot system into two different kinds of files.

I think at the end of the day this change would have to happen in Julia itself first.

In an ideal world we could create a Mac app store submission that ships the launcher and juliaup and have everything work on Mac as well.

The launcher is just a small C++ program that probably could be made cross-platform fairly easily. Juliaup is written in Julia in any case.

Main question is to figure out how one can package something as a Mac app store submission, really.

Checking at app start causes a delay. We could also configure it to only check on app start every x hours.

At the moment we store the default Julia version as a UWP configuration property. That is very Windows specific and doesn't really buy us anything, so it would probably make more sense to store this (and other config options) in a file ~/.julia/juliaup/juliaup.toml or something like that.

Right now one can pick a Julia version specifically by giving a full version number. For example, one can configure the default Julia version to be 1.4.2. We should add "channels" as alternative ways to pick a Julia version.

Useful channels could be 1.2 (=latest build in the 1.2 series), 1 (=latest build in the 1 series), latest (=latest released version), lts (=latest LTS release) and maybe nightly (=latest nightly build).

One could then specify a channel as a choice, for example one could run juliaup setdefault 1.4 to make the 1.4 channel the default that gets invoked with julia.

For each channel, we would want a user changeable configuration that specifies how this channel will update. Useful values might be auto (always automatically update to the current build in this channel), prompt (prompt the user when a new version is available in that channel to update) and never (don't even tell the user about any new versions in the channel).

A good default out-of-the-box configuration might be latest as the default channel, with an update setting of prompt.

Both are currently placeholder versions, but should properly check for valid input.