Release Builds on WinGet Pkgs

[ntindle]

Please add support for WinGet Packages releases.

Details on how to available here: https://github.com/microsoft/winget-pkgs

[alexandregv]

This will need to have a downloadable .exe or .msi installer, available from a single link.

https://github.com/microsoft/winget-pkgs#authoring-a-manifest

InstallerType: string # enumeration of supported installer types (exe, msi, msix)
Installers:
  - Arch: string # enumeration of supported architectures
    URL: string # path to download installation file
    Sha256: string # SHA256 calculated from installer

Currently the recommended installation method is to use https://deno.land/x/install/install.ps1, which is a PowerShell script, not an exe/msi installer, so it's not usable in winget manifest.

Actually, and as @MarkTiedemann explained in this comment, there is an exe file available in deno github releases, but it's not really an installer (just the deno executable), and it's inside a zip file, so we can't download it directly as winget manifest wants.

Related issue #5727

[MarkTiedemann]

For reference, there's a list of supported package managers here: https://github.com/denoland/deno_install#install-via-package-manager

@alexandregv is right. Currently WinGet does not support simply downloading an exe in a zip, but requires an installer. There is a related issue regarding installing curl, which is also distributed as just an exe in a zip (see https://curl.haxx.se/windows/), here: https://github.com/microsoft/winget-pkgs/issues/726.

Might be good to open another upstream issue for allowing binary "installations".

PS: I'd recommend using Scoop to install Deno on Windows. It's always up-to-date, it allows you to install different versions of Deno, and uninstall is just a single command as well.

[MarkTiedemann]

Just had another look and found a bunch of related upstream issues:

• https://github.com/microsoft/winget-cli/issues/140
• https://github.com/microsoft/winget-cli/issues/182
• https://github.com/microsoft/winget-cli/issues/194

So time to get a coffee and wait for Microsoft to fix this. :)

[MarkTiedemann]

On a related note, I think this issue could be moved to https://github.com/denoland/deno_install.

cc @bartlomieju

[Spoonbender]

@MarkTiedemann how about creating an MSI installer for Deno? If such a PR is issued, is there any principal reason for it to be rejected?

[MarkTiedemann]

@MarkTiedemann how about creating an MSI installer for Deno?

In general, I think that's a good idea and it's definitely a fix for this issue, though, as mentioned in the comments above, I do think that WinGet should just support plain executables rather than requiring an installer, and so I'd rather have this specific issue fixed upstream.

That being said, it's, of course, still a good idea to create a GUI installer. I think the main reason for doing that would be to be more beginner friendly. As witnessed in https://github.com/denoland/deno/issues/5727, people may not expect Deno to just be an .exe in a .zip. Since setup.exe or setup.msi installers are a common pattern on Windows, I think it's fair to offer this to users.

(Another potential "fix" for that problem would be to educate people that an installer in the classical sense isn't really needed. There's an issue for that in deno_install: https://github.com/denoland/deno_install/issues/130)

I think there's also a question of scope: deno_install and deno upgrade allow you to install the latest or a specific deno version to the default or a specific location, adding that location to the %path%. So the installer should have those features at least. Both don't have an "uninstall" feature - that'd be a potential new feature. Both also don't have the role of a version manager - not sure whether that would be in-scope: Personally, I'm using MarkTiedemann/dvm.cmd to manage my deno version on Windows, axetroy/dvm to manage my deno version on MacOS, and MarkTiedemann/deno.mk for cross-platform project-local installations. So I think it'd be great if the installer was aware of previous downloads and if you could switch the deno version that you want to download/use in the setup, but that's certainly not a requirement - just my personal preference.

Then there's a couple of questions in regards to "How do you actually build the installer?". Which languages? Which tools do you use? What's the build process? Do we need to sign the installer? And if so, how do we sign it? etc.

PS: I have previously started a deno-up.exe project, but I have abandoned it since dvm is covering all of my needs.

If such a PR is issued, is there any principal reason for it to be rejected?

I don't accept nor reject PRs so that's not a question I can answer. I'd gladly help review, but ultimately that's up to @ry, @piscisaureus and @bartlomieju to decide, I guess.

[josuemb]

Just FYI: Today Microsoft is releasing winget as GA. Probably is time to give it a look again.

[MarkTiedemann]

While winget is v1 now, it still doesn't support standalone binaries. The linked upstream issues are unresolved.

The related v0.18.x milestone for standalone binaries was closed 23 days ago with 0% complete.

[josuemb]

Probably https://wixtoolset.org/ can help to do the job. It help to make good installers.

[MarkTiedemann]

@josuemb Why should we create an installer if winget plans to support standalone binaries in future? Again, this issue is blocked upstream.

[josh-hemphill]

Looks like microsoft has added standalone executables to their manifest spec in the latest release. Here's the specification: https://github.com/microsoft/winget-cli/pull/2012 And the implementation: https://github.com/microsoft/winget-cli/pull/1930 It's only in pre-release, but I think we're coming up on another release soon, the community package repo might start accepting app manifest PRs with it soon.

[dhruv-m1]

@josh-hemphill This will be available in the next release (v1.3.x), scheduled for July 31, 2022 . Probably a good time to look at this issue.

From winget-cli/milestone/37:

Notable features:

Support for portable / standalone executables Preliminary work to integrate with Intune

Moved to 1.4

Support for .zip files containing installers and/or executables

The release candidate is available here

[MarkTiedemann]

Thanks, @dhruv-tech. Then we'll have to wait until v1.4 since Deno's executable is shipped in a .zip file.

[MPThLee]

Last week, Winget 1.4 is released as stable. So should we submit the package to winget? CC: https://github.com/microsoft/winget-cli/releases/tag/v1.4.10173

Edit: Ah it is 'stable' but not 'Generally Available'. sorry! Edit (2): Seems like zip file packages are not accepted on community repository until GA, but can be tested with local manifest.

[josh-hemphill]

Yep, I tested winget-create against the zip from the github release artifacts from deno releases, and had to submit a PR to fix a minor bug over handling executables that don't have embedded manifests, but it works now; so you can just run that against a github release of Deno, to generate a basic manifest for Deno. Though you'd probably just want use that to get all the parameters so it can be generated and published in CI.

[MarkTiedemann]

Deno is now available as an official package: https://github.com/microsoft/winget-pkgs/tree/master/manifests/d/DenoLand/Deno

You can install it with winget by running:

winget install -e --id DenoLand.Deno

Note that changes to the Path variable will not be reflected directly so you may need to restart your terminal or logout/login again.

I think this issue can be closed now. @dsherret

[jakubmazanec]

The documentation wasn't updated; there's no mention of an option to install via winget: https://deno.land/[email protected]/getting_started/installation

Also, the version available via winget is 1.30.3, while the latest is 1.32.3.

[MPThLee]

Because Winget community package repository is being maintained by community users. As it need to submit the manifest by every update. Some of other programs are using some github actions(or something like that) for auto-pr on release. (Like this action)

I think Deno Land should care this.

[kt3k]

We removed the winget command from the manual because the package is out of date in winget registry https://github.com/denoland/deno-docs/pull/63

[lilnasy]

Deno on winget is currently updated automatically by a GitHub action written by a winget contributor (Thanks @CoolPlayLin!). I think this issue can be closed.

[CoolPlayLin]

@kt3k Any of version will be published by my bot using github action in one hour when it has been released. The merging of it would take time. So, you shouldn't remove winget command.

[josh-hemphill]

It should really be part of Deno's own github actions, so the Deno team feels comfortable listing it in official docs. I made sure that winget's winget-create works with Deno, so whether it's that or another tool in a github action, it should just be some properties and a one-line command...

I really don't see any reason it shouldn't be added to the main repo. 🤷

[lilnasy]

Not sure if it makes sense to add that maintenance burden. None of the other package managers are created or updated by the core team. So if they start with winget, where do they draw the line?

[kt3k]

@CoolPlayLin @lilnasy Thanks for pointing it! We misunderstood the situation because winget.run page is outdated. We fixed the issue in https://github.com/denoland/deno-docs/pull/113 (Thanks @lilnasy for sending the PR!)

[kt3k]

@CoolPlayLin Thank you!