How do we support VS Code Insiders in winget?

[Tyriar]

Related: microsoft/winget-pkgs#277

code-insiders is published approximately daily, while we could automate a PR for stable I don't think it makes sense to do this for Insiders. We have a web endpoint that points to the latest version, can we just not include a Version in the manifest?

@KevinLaMS

[KevinLaMS]

Hey Tyriar:
I think what you are asking for is channel support?
I will be happy to sync with you on this:
#147

[Tyriar]

@KevinLaMS no not channels, we ship as 2 separate binaries such that you can install side-by-side. I'm envisioning what we do with the Linux packages where there is a separate app code-insiders that is defined separately to code.

Insiders is published to a lot, and we also need to be able to delete versions, this is all handled by the built-in updater. Another way of saying what I'm after is whether it's possible to create a https://github.com/microsoft/winget-pkgs/blob/master/manifests/Microsoft/VisualStudioCodeInsiders/latest.yaml where Version is either unset or set to something like latest, and then point it to our endpoint that downloads the latest insiders.

[Tyriar]

We also have an "exploration" build which is available on other platform package managers too:

http://packages.microsoft.com/repos/vscode/pool/main/c/
http://packages.microsoft.com/yumrepos/vscode/
https://snapcraft.io/code
https://snapcraft.io/code-insiders

[RobertBernstein]

So before I saw this issue and microsoft/winget-pkgs#327 , I tried creating my own manifest file for VS Code Insiders (using .\YamlCreate.ps1) and was going to submit a PR. However, while the manifest file passed validation, the installation failed using winget.exe install -m .\1.46.0.yaml. I got the following dialog box:

Here is my manifest file:

Id: Microsoft.VisualStudioCodeInsiders.UserInstaller
Version: 1.46.0
Name: Visual Studio Code Insiders (User)
Publisher: Microsoft Corporation
License: Copyright (c) Microsoft Corporation
AppMoniker: vscodeinsiders
Tags: vscode, insiders, editor
Description: The Visual Studio Code Insiders build is a code editor for early adopters that is optimized for building and debugging modern web and cloud applications.
Homepage: https://code.visualstudio.com/insiders/
Installers:
  - Arch: x64
    Url: https://az764295.vo.msecnd.net/insider/da3bf754c3c0eabda1dc80ed9d627679ee560697/VSCodeUserSetup-x64-1.46.0-insider.exe
    Sha256: 21D54D6B34B63F1FB41B0D21816E9B1CF1A5E1578AF810A805D3CE2086B2E773
    InstallerType: Inno

There were no logs files that I could find in the %temp% directory. I tried specifying -o .\log.txt, but that also produced no log file. How can I understand why it failed? Should I open this as a separate issue?

Thanks in advance.

Rob

[KevinLaMS]

@rob, when did you get that error? I just ran the yaml you provided in the same command "winget install -m and it installed.
The dialog seems odd. Did it install at all?

the Logs should be here C:\Users<user>\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir\

[RobertBernstein]

Thanks, Kevin. It didn’t install there at all. I didn’t look in the Local\Packages directory for the logs. I’ll check that and get back to you.

On Tue, May 19, 2020 at 9:59 PM Kevin Larkin (MS) ***@***.***> wrote: @rob <https://github.com/rob>, when did you get that error? I just ran the yaml you provided in the same command "winget install -m and it installed. The dialog seems odd. Did it install at all? the Logs should be here C:\Users<user>\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir\ — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/microsoft/winget-pkgs/issues/278#issuecomment-631187597>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGON5YTKTK2FOWS6RWEIK3RSM2OHANCNFSM4NFFAQ4A> .

-- Rob

[NatoBoram]

I think it's worth to take a look at Scoop's solution to this problem when they added support for rust-nightly. ScoopInstaller/Scoop#181

[denelon]

@Tyriar one of the concerns here is the SHA256 changing with each build. Not only would we need to point to "latest" and essentially ignore "version", we'd need to do the right thing with respect to an unknowable hash.

[RobertBernstein]

@denelon In the Scoop solution mentioned by @NatoBoram, they ignored the hash value.

[denelon]

@denelon In the Scoop solution mentioned by @NatoBoram, they ignored the hash value.

I'd still prefer having an automated path to getting manifests with a hash.

This may be better served by multiple source repositories. The work we're doing on the REST API should make it trivial for another entity to stand up their own repository and essentially be in control of their own destiny with respect to the packages installed. When someone adds a new source, all of the appropriate warnings and elevated permissions things can happen one time rather than every single install.

[denelon]

#118

[denelon]

As the Visual Studio Code release version and the insiders can be installed "side-by-side" we are looking at generating a manifest and having the submission as part of their release process. We would have the standard package and manifests for the release version. As well as the daily insiders build.

[WSLUser]

Couldn't you fetch the hash for comparison if you don't want to ignore it? You should be able to get this from Github at the very least.

[denelon]

The Visual Studio Code team via @lszomoru is now publishing manifests for daily/nightly builds. They have been for some time. I just came across this discussion again so I wanted to mark this as answered.