[Update Request]: Julia

[davidanthoff]

What type of update are you requesting?

A new locale, architecture, or installer type of an existing version

Current Package Identifier

Julialang.Julia

Package Version

More generic

Please describe the changes you would like to see

This is a more general discussion/question what we should do about the Julia programming language in this repo here. For a bit of background:

• https://github.com/julialang/juliaup based installers are now the recommended way to install Julia on all platforms and we are trying to make sure that as many package managers/stores etc offer a Juliaup based installer for their Julia package.
• Julia in the Windows Store has always used a Juliaup based installer. So winget install julia -s msstore works and is currently officially the recommended way to install Julia on Windows.
• This repo here has manifests that point to the now legacy inno based installers for Julia, one can get those via winget install julia -s winget.

In general, I think it would be good to phase these inno based installers out and try to make sure that all roads lead to a Juliaup based setup. Right now, I see two ways to do this:

1. Just entirely remove Julia from this repo here and only offer the Windows Store version via winget.
2. We have MSI (and also MSIX) based installers that are part of the Juliaup story, and we could replace Julia here in this repo with a manifest that points to these MSI installers that utilize Juliaup.

I think the only benefit of 1) in my mind would be that winget install julia would work, i.e. we would no longer need the -s msstore flag for the default case. But on the flipside, there are user systems where the Windows Store is blocked, so that is not ideal. Plus, maybe at some point winget will provide some way to prioritize a Windows Store version, so maybe if we just wait winget install julia will just automatically install from the store, if a user system has the store available, in the future.

The main benefit of 2) is that we might be able to target slightly more systems, e.g. server systems, system wide installs etc. That is based on the assumption that there are systems out there where winget with a MSI installer works, even though the Windows Store is say blocked by an admin. Not sure whether that is really so.

If we were to go with 2), we could also entirely automate the updates of the manifests here, we do that already with other package managers.

In any case, I wanted to open this issue to get some feedback how we should best proceed. I'll CC everyone who in the past has contributed to the Julia manifest in this repo in the recent past: @jarredclloyd, @torculus, @ZenanH, @OfficialEsco, @Trenly, @vedantmgoyal2009.

[SpecterShell]

You can also add the APPX based installers to this repo, so WinGet will be able to download and install them from the official server instead of the Microsoft's one. (By the way the App Installer points to a pre-release version while the one on Microsoft Store points to the stable version. Is this intentional?)

The MSI based installer currently available on the server may not be suitable for WinGet as it seems to write the same version (1.0.0) to the registry, which causes WinGet not able to detect the actual version of the Juliaup installed and thus propose updates.

How about downloading the archive and linking the executable (julia.exe and juliaup.exe) directly? The only issue is that WinGet currently does not support tar archive and you may need to repack them into zip archive.

(Should the package be renamed to Julialang.Juliaup to avoid being ambiguous?)

[davidanthoff]

@SpecterShell, ah all very interesting!

Can you maybe shed some light on what we actually gain from having anything for Julia in this repo here, when it is already in the Windows Store? Am I right that the main benefit would be that for users where an admin has blocked the Windows Store, things would work? Or is that actually the case? I don't fully understand whether winget actually works if an admin has blocked the Windows Store, because winget itself is somehow distributed via the Windows Store, right?

I was thinking the benefit of an MSI option would be that one can do a system wide install. Would that also be possible with the portable zip file option?

Is there any benefit from adding the appx based installers here? In my experience that has been by far the least stable setup option, there seems to have just been a log of bugs in various Windows versions with that tech....

By the way the App Installer points to a pre-release version

No, that is not intentional, I'll check what is going on there, thanks for pointing that out!

The MSI based installer currently available on the server may not be suitable for WinGet as it seems to write the same version (1.0.0) to the registry, which causes WinGet not able to detect the actual version of the Juliaup installed and thus propose updates.

I'm fairly positive we can fix that, I'll presumably just need to set something in the WIX files properly that I'm missing right now.

How about downloading the archive and linking the executable (julia.exe and juliaup.exe) directly?

That might be nice! Can we create start menu shortcuts that way, and put things on the PATH? And can we do system wide installs with that? If the answer to those questions is all "yes", then that definitely seems better than the MSI option.

Should the package be renamed to Julialang.Juliaup to avoid being ambiguous?

We really want to phase the old installers out and make these new installers the default installers for "Julia", so ideally we would publish these new installers as just "Julia".

[SpecterShell]

I don't fully understand whether winget actually works if an admin has blocked the Windows Store, because winget itself is somehow distributed via the Windows Store, right?

WinGet is independent of Microsoft Store and is actually a part of the lower-level "App Installer" program. One can also obtain the WinGet client (or the "App Installer" program) installer from https://github.com/microsoft/winget-cli/releases, either install it or extract the executable from it, and run it without using the Microsoft Store.

That might be nice! Can we create start menu shortcuts that way, and put things on the PATH? And can we do system wide installs with that? If the answer to those questions is all "yes", then that definitely seems better than the MSI option.

WinGet can put things on PATH (That is what the portable type intended to do). WinGet can also do system-wide installs (By running WinGet in admin context with the --scope machine switch). But currently WinGet can not add start menu shortcuts for them.