Portable / Standalone Executables

[denelon]

I'm working on the specification for Portable / Standalone Executables #182

This discussion is to help consolidate discussion for this feature.

Note: This is not the same as support for .zip or other compressed packages, but it is one of our prerequisites.

[denelon]

microsoft/winget-pkgs#2594 (comment)

There has been an ask for the ability to rename a package.

I'm debating the value of using the "command" key in the manifest for renaming the package to the "suggested" command. We could also provide a "--rename" argument to allow the user to specify the name of their choice.

An example is GitLab Runner: According to their documentation, they suggest renaming the executable after download.

[denelon]

If we were to use something akin to a symbolic link or shim, or App Execution Alias, that would be harder to maintain if the binary had a name change.

[denelon]

When we think about adding support for this in the Microsoft Store, it's best if we have the value to use for running the program in the manifest. I still see value in supporting "--rename" for developers who are using the Windows Package Manager CLI though 😊

[jedieaston]

Sounds good. In that case I'd hope that the command field was required for portable/standalone, as it's currently a nice-to-have.

[RobCannon]

I think installing a portable app with a versioned name and creating a symlink/shim for the friendly name should be considered a best practice. It prevents issues with installing the new version if the old version is still in use, for instance.

[denelon]

I think the challenge with this is the risk of leaving files on the system as users upgrade. We would end up potentially with multiple entries in Apps & Features (one for each version of the package) and all of the files from the earlier versions. When we think about "upgrade" the idea is to simply upgrade the version. If the program is running, we want to be able to inform the user that it's running so they can shut it down / stop it before upgrading.

[majkinetor]

Maybe I am late to this party but here it is anyway...

Can we get some info on how this would work? Speaking as someone who created hundreds of such packages on Chocolatey and the AU framework (which I could make work with winget eventually) I have some questions and notes:

1. Would I be able to pack random binaries into a package? This is is essentially what is needed for this to work, not only because of portability but also because this should be the preferred way of making packages given that they can then be cashed locally (via NAS, Artifactory, or Nexus for example) which makes them stable (not depending on network or vendor distribution model changes and having a stable list of previous versions) which mean that they can be depended on during build or CI/CD procedure. Without this option, you can't use winget for anything more serious but private OS customization.
2. Regarding leaving files on the system as users upgrade, that may be non-issue if upgraded files overwrite the previous one. Having it differently is funky, and makes almost 0 sense, as its not only about files but about migration configuration which can be hardcore or on some cases impossible if apps keep config in binary format like foobar2000.
3. It's way more important to have install than uninstall for portable packages. In many cases, it's not wise to remove those - for instance packages like influxdb or rundeck keep the production data in the install folder so by removing them you would destroy them, so in such cases it's best not to touch it.
4. What would be the size limit of such a package. Today, many, even simple tools can be 200+ MB in size.
5. Regarding keeping binaries on PATH, given that it is limited in size, one way to do it is to register them using AppKey system. They will not be immediately available in CLI, but with simple intervention they could (this could be supported by terminal natively). Other variant is to use shim to standard location which is added to PATH, but it has its own problems and surprises too, although it seems to mainly work.
6. Not sure what is the PowerShell support status, but this totally requires it, because some installation procedures may be quite comprehensive.

I didn't yet use winget precisely because of this missing feature. If I can do more with this experience let me know and I can dive in deeper.

[denelon]

@majkinetor the portable specification covers a single executable binary.

1. I think you may be referring to the .zip feature. Initially, we're thinking about a compressed file containing a single executable or a single installer and optionally other files. As we have additional clarity on other common scenarios, it can be extended.
2. I'd love to get your take on the upgrade mechanism we're considering. Using foobar2000 as an example might enlighten us, and justify some additional metadata in the manifest to help with upgrade scenarios. In general, we would like to ensure we have settings for default behaviors and pairs of opposing arguments so they can be overridden.
3. This sounds like more justification for a deeper dive on number two if our current thinking would be a bad user experience.
4. We haven't imposed size restrictions to date. Some installers are already in the GB range.
5. We've landed on using symbolic links in a single directory (per scope) on the path.
6. PowerShell will be supported as a native interface to the Windows Package Manager, but one of the primary design decisions has been to avoid scripting behavior. That does limit what the Windows Package Manager will "do" on its own. That doesn't mean one couldn't construct a package with additional steps necessary to achieve the desired outcome. The main difference (in my opinion) is the perception of liability and the risk associated with attempting to ensure all scripts are safe to run.

The current preview as of today (May 10th, 2022) is our first release with experimental support for installing portable applications. It will require either using local manifests or some scripting to run manifests in PRs. If you're interested in testing it out, let us know. I'm sure some of the more prolific contributors would enjoy the collaboration. We also have an ongoing chat in Gitter.

[maphew]

Is there a feature or method to search package index for only portable apps and exes?

[maphew]

there is winget search --tag portable but I'm not sure how robust or reliable it is (there's only 28 items listed at the moment).

[denelon]

No, and "--tag" is just a metadata property that isn't correlated with "--installer-type". Feel free to create a feature request to be able to search by installer type.

[maphew]

I tried twice to open an issue and it seems to have failed. The 1st time I used the [...] at right and reference in new issue. While composing the description I used ctrl-k to insert a hyperlink, a dialog appeared on top with some unfamiliar and unrelated instructions. I hit esc and both the popup and the compose dialogs disappeared. I used reference in new issue again, and saved right away, then edited in the standard github new issue page. After finishing and submitting I returned to my Notifications page, and now there's a new item: https://github.com/microsoft/winget-cli/actions/runs/7747136718 whose title seems possiblty related (duplicate comment) but the content is very different(?)

I know this post is better opened as new issue somewhere in GH as a UX bug, but I've no idea where that is, and need to write this down now while fresh in mind

[denelon]

https://github.com/microsoft/winget-cli/issues/new/choose

From there you should be able to select "🚀 Feature Request / Idea"

[maphew]

... Feel free to create a feature request to be able to search by installer type.

ok, the new issue did work after all. However the system generated link which usually appears in context with the source discussion has been removed. Presumably as a consequence of the UX bug I described. Here's the request: #4131

[maphew]

I know this post is better opened as new issue somewhere in GH as a UX bug, but I've no idea where that is, and need to write this down now while fresh in mind

Found what I hope is the right spot and filed it: https://support.github.com/ticket/personal/0/2570211