Create a WinGet package

[rashil2000]

The official package manager, WinGet does not support publishing PowerShell scripts and modules. Only supported formats are .exe, .msi, .msix.

The solution is to use a well-known executable creator - PS2EXE. Really simple program, it takes just one command to create a single full-fledged Windows executable (.exe).

The advantage of this is that we will have something to put out in our releases page, which can be picked up automatically by the WinGet manifest. Also, this will allow calling winfetch from any shell - CMD, Bash, WSL etc. - just like Scoop does (Scoop creates a shim so it's a slightly different method). The obvious downside is that, when used from PowerShell, it's slower because it's an executable as compared to a shell script. From other shells it makes no difference. In fact it was faster in my testing, when done from CMD.

The publish-psgallery branch can be repurposed as a general package-management branch (free of source files) - for hosting PSGallery, Scoop, Chocolatey and WinGet manifests and other related assets.

[jcwillox]

The publish-psgallery branch should not be touched it will hopefully be merged into the master branch, as Github workflows are only triggered if they are on the master branch. If we were creating a branch just for general publishing/packaging we wouldn't call it publish-psgallery.

I don't think the exe file should be quicker as I'm pretty sure it just bundles the script and calls PowerShell externally, any speed difference might be coincidental, make sure you use -NoProfile -NoLogo when comparing. In any case, the exe file is not going to be as good, it's slower when calling from PowerShell and will lose tab completion. If someone wants to call winfetch from WSL, etc. they can always just run pwsh.exe -nop -c "winfetch". Seeing as we don't need to use an exe file to create a chocolatey package (see my comment on #38), it's probably not worth doing.

As for WinGet, it would add an additional layer of complexity as last time I checked it only supports installing using a setup, it won't download and add binaries to the users' path. And to be honest users of winfetch are probably using either choco/scoop, or are happy to use PSGallery/manual.

[rashil2000]

The publish-psgallery branch should not be touched it will hopefully be merged into the master branch, as Github workflows are only triggered if they are on the master branch. If we were creating a branch just for general publishing/packaging we wouldn't call it publish-psgallery.

I was not asking to use the same branch, I was asking to use a different one for management (I said 'repurpose').

Seeing as we don't need to use an exe file to create a chocolatey package (see my comment on #38), it's probably not worth doing.

I changed this issue to address WinGet specifically, chocolatey now has no relation to this issue.

And to be honest users of winfetch are probably using either choco/scoop, or are happy to use PSGallery/manual.

That is not really a good sentiment. While Scoop and Choco are far more popular, none of them are still official. If we plan to target widespread adoption in the Windows realm, it makes perfect sense to have a package in the official manager. Even the PSGallery one that we have is technically 'unofficial' at the moment.

We can certainly wait till WinGet provides easier methods to install our script; dismissing it is not really ideal.

[jcwillox]

That's kinda what repurpose means, but yes we'll create a separate branch for storing the chocolatey and possibly winget package files.

I agree it does make sense to support WinGet at some point. I wasn't discounting it entirely, but we should probably support the other installation methods first, and seeing as WinGet is still in beta and very basic we might be better off waiting until they actually support some other installation methods.

[rashil2000]

any speed difference might be coincidental, make sure you use -NoProfile -NoLogo when comparing

@jcwillox Just FYI, I feel I know PowerShell well enough to factor those parameters in.

In any case, here are the benchmarks, giving consistently better times for the executable.

(with battery saver on)

(with battery saver off)

The PS2EXE script is over 2700 lines long, while I don't have the capacity to understand the .NET APIs it is using (the winfetch script gets converted to some C#-Assembly hybrid, and then compiled), I would really think it is doing more than just bundling the script with a string command. The results above won't really make sense if not for some optimizations done within PS2EXE.

[jcwillox]

I was pretty sure you knew that, but sometimes people forget the most obvious things, and the -nop was probably the most obvious reason I could think for it to be slower.

That's very interesting, you're probably right it definitely seems that they're doing some fancy stuff with it that ends up making it faster.

[rashil2000]

Some additional points which might be obvious, but are still worth mentioning:

• Tab completion doesn't work with scoop (because of the shim)
• While I agree PowerShell is the way forward and far modern, many people developing/using Windows still prefer using Git Bash, and now WSL, simply because of the unix background of those shells. For those people, doing pwsh.exe -nop -c "winfetch" every time is really cumbersome, and as the benchmarks above show, slower too. Tab completion anyways doesn't matter for those shells (even for CMD it doesn't work), so it's not really a deciding factor there.
• To target package managers, it makes more sense to provide executables so as to provide better system-wide usage. For PowerShell alone, only the PSGallery method is really ideal as it preserves both the tab-completion and the script's faster speed.

[jcwillox]

• Well it does with New-Alias winfetch "~\scoop\apps\winfetch\current\winfetch.ps1"
• And again alias winfetch='pwsh.exe -nop -c "winfetch"'. Also, most package managers are capable of generating executables for CMD/bash, for example when installing with scoop I can use winfetch in all my various shells (cmd, bash, ...) without an issue. I wouldn't say speed is a deciding factor, in fact, I found the exe was just as slow as the scoop shim within wsl, which really makes it redundant.

• And yes as you said PSGallery tab completion works, choco might as well, scoop can too with an alias (there was actually a feature request for including completion with PowerShell shims).

I agree that using an exe does make it easier for it to work in different shells, but if the package manger can create shims then we should let otherwise it seems unnecessary to use an exe, as well as sacrificing speeding in our target shell and tab completion.

[rashil2000]

• Well it does with New-Alias winfetch "~\scoop\apps\winfetch\current\winfetch.ps1"

Scoop already creates a shim, I don't see any reason users wanting to do this extra step.

...tab completion works, choco might as well...

Again, only if you alias to that particular script location.

Both these methods defeat the purpose of package managers automatically downloading and setting up shims/executables. An extra alias is not going to be helpful, notwithstanding the fact that the shims created by package managers would go useless (in this scenario). And all of this still applies only to PowerShell, which as I said, is still not the most used shell on Windows.

[rashil2000]

To be fair, I agree our primary target is PowerShell users. For that reason, I would really suggest making PSGallery as the primary recommended (default) method of installation, instead of Scoop (which sacrifices both speed and tab-completion).
We anyways have other methods listed in our installation page, but we should be going with the default supported method that allows for full enjoyment of our project.

Pinging @kiedtl again (sorry for nitpicking), but it'd be great if you could just set up the NugetApiKey in the GitHub secrets section. Everything else has been set up by @jcwillox; that key is the only thing we need to officially publish lptstr-winfetch.

[russellbanks]

This hasn't been visited in a while and I still think it's valuable to have this on winget, regardless of the primary target audience. I'd be happy to add it, but I need something to work with, whether that's an installer, standalone executable, etc

I have tried myself using ps2exe as suggested, and have successfully created a standalone executable, which would be able to be used with WinGet (they create their own links/shims).

I have forked the project and have published my fork of winfetch to winget. It is by far a slower alternative, but still an alternative I would like to have available. I'd love for this to be available officially on winget (published under kiedtl) and I can then remove my fork.