Pin a package

[denelon]

Description of the new feature/enhancement

Users should be able to prevent the Windows Package Manager from updating a package (assumes the package doesn't have it's own auto-update).

winget pin <package> and the corollary winget unpin <package>.

This was mentioned by:

@megamorf #120 (comment)
@rodalpho #120 (comment)
@aetos382 #120 (comment)
@kmindi #120 (comment)

Proposed technical implementation details (optional)

There should also be a mechanism to display the packages (and the version) that have been "pinned". This might be a function of list or a function of pin. Additionally, if packages are known to self-update (like Visual Studio Code) an additional meta-data entry in the manifest could help users understand when they may not be able to pin a package.

Edit: Clarifying behavior for ambiguity suggested in other Issues.

Pinning should enable users to specify the exact version (likely the default case with no parameters).
It should also allow users to specify what portion of a version should be pinned so bug fixes could be applied, or even minor version bumps.

Note: the syntax below is just suggestive.

Assume the user has installed "Awesome App" version "1.2.3".

winget pin "Awesome App"
This would pin to version 1.2.3 and would not be upgraded when any newer version is released.

winget pin "Awesome App" --version 1.2
This would pin version to anything less than version 1.3. If version 1.2.4 were released this would be a valid upgrade.

winget pin "Awesome App" --version 1
This would pin the version to anything less than version 2. If version 1.2.4 were released this would be a valid upgrade. If version 1.3.0 were released this would also be a valid upgrade.

Additional example per @brainz80

E.g. Having nodejs-lts version 12.1.1 installed and running winget pin --all nodejs-lts --version 12.x should make it so that when later winget upgrade --all is ran it'd check if there is a update available for nodejs-lts what matches 12.x - if the latest update is e.g 16.1.1, but there is also a 12.1.2 it'd update nodejs-lts to that version.

[megamorf]

From my experience the most common scenario for why you'd want to pin a package version is when there is a known issue with a newer version of that package itself or with one if its dependencies. So on Linux that meant I pinned the docker package because one of its dependencies (containerd) could not be installed.

winget must be able to resolve dependencies (once implemented) for this feature to be really useful since it needs to block the update of all packages that have the pinned package listed in their dependencies.

---

I also like pinning because it allows me to rely on software that is prone to change a lot (for example when it's early in development) and I can rest easy that it will stay the same unless I explicitly unpin it again.

[brunovieira97]

From my experience the most common scenario for why you'd want to pin a package version is when there is a known issue with a newer version of that package itself or with one if its dependencies.

I don't see it exactly that way. I could simply block an app, let's say NodeJS, of installing updates because I'm developing stuff that is tested only against a specific version of such package. Anyway, there's lots of use cases, specially for devs.

[megamorf]

I don't see it exactly that way. I could simply block an app, let's say NodeJS, of installing updates because I'm developing stuff that is tested only against a specific version of such package. Anyway, there's lots of use cases, specially for devs.

That's what nvm (node version manager) is for ;-) My line of work is DevOps and most of the times this has been necessary was due to issues in operations but your experience may vary.

[domoaligato]

I think that this might be related or something need to be put in place to support software versions that are higher than the repo versions.
Here is my example:
I have opted into the Beta versions of Battle.Net
This is before a upgrade.

winget upgrade
Name                  Id                          Version    Available    Source
--------------------------------------------------------------------------------
Battle.Net            Blizzard.BattleNet          Unknown    1.22.0.12040 winget

winget upgrade Blizzard.BattleNet
Found Battle.Net [Blizzard.BattleNet]
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading http://dist.blizzard.com/downloads/bna-installers/322d5bb9ae0318de3d4cde7641c96425/retail.1/Battle.net-Setup-enUS.exe
  ██████████████████████████████  2.73 MB / 2.73 MB
Successfully verified installer hash
Starting package install...
Successfully installed

The Client then opens and updates itself to the latest beta version and shows the same results as before.

winget upgrade
Name                Id                          Version   Available    Source
-----------------------------------------------------------------------------
Battle.Net          Blizzard.BattleNet          Unknown   1.22.0.12040 winget

Maybe this is just something wrong with the packages and this functionality is not needed, but Discord.Discord , GOG.Galaxy, EpicGames.EpicGamesLauncher all have this issue.

[Croydon]

Additionally, if packages are known to self-update (like Visual Studio Code) an additional meta-data entry in the manifest could help users understand when they may not be able to pin a package.

As a note, please don't block pinning of packages that are known to self-update / have own updaters. I'm using package pinning in chocolatey also for packages, which I want to update via another mechanism than chocolatey itself. I think this is a valid use case too.

[theodiefenthal]

From my experience the most common scenario for why you'd want to pin a package version is when there is a known issue with a newer version of that package itself or with one if its dependencies.

Two more usecases (well one and a half):

1. Licensing. After I now installed winget, I see it could update my PDF-XChange-Editor, but I only have a license for version 8, so I don't want winget to upgrade it to version 9 and instead, I decide myself when to buy a new license and manually upgrade.
2. I see that WinGet wants to update my NextCloud client. The latest two versions work in principle but due to some issues with my own nextcloud installation, it doesn't work with my specific server. So I'll stick for a while with an older version whereas for most other users, those newer versions work fine.

[Soitora]

From my experience the most common scenario for why you'd want to pin a package version is when there is a known issue with a newer version of that package itself or with one if its dependencies.

Two more usecases (well one and a half):

Personally, I'd like to block Python as I got multiple Python installations if it's needed, which it has been in the past for a few niche programs. But it wants to update all of them to latest.

[bchap1n]

I just tried 'winget upgrade --all' for the first time and it tried to upgrade Audacity to 3+ which is now suspected for spyware. Audacity 2.4 is safe and will remain very popular. I didn't install Audacity with Winget (I used Scoop and pinned it). If Winget is going to upgrade apps installed via Scoop or Choco then we need to be able to pin.

[denelon]

@BrianL-STCU try https://github.com/microsoft/winget-cli/releases/tag/v1.5.441-preview

[lackovic]

I don't see any instructions for installing a pre-release version at that link. I've enabled pinning in the settings.json in v1.4.10173, but winget still tells me to enable pinning in settings.json when I try to use it.

Pinning functionality is not present in version 1.4.10173, even though the commands for it are. See #2979

[ksl28]

Just had the pleasure of testing the preview version, and the pinning feature is exactly what i was hoping for!
But i hope that they will add a way, to specify it by parameter like chocolatey --except - so that it can be invoked to clients, without having to edit the settings.json file

[denelon]

@ksl28 we've released it in a preview as an "experimental" feature. Once this is a stable feature, we will release a version that no longer requires enabling the experimental feature.

We've used this pattern in WinGet so we can continue to iterate on features until they become stable. Pinning is currently experimental so we can get user feedback on how it is working, and hopefully and bugs identified can be fixed before the feature becomes stable.

The open Issues related to winget pin represent the current state of the feature.

[norahvii]

Changed my settings to:

{
    "$schema": "https://aka.ms/winget-settings.schema.json",

    "experimentalFeatures": {
        "pinning": true
    }
}

Still wouldn't allow me to take advantage of the feature. What other steps are needed?

[mdanish-kh]

Changed my settings to:

{
    "$schema": "https://aka.ms/winget-settings.schema.json",

    "experimentalFeatures": {
        "pinning": true
    }
}

Still wouldn't allow me to take advantage of the feature. What other steps are needed?

Did you update your client to the 1.5 preview release?

[vrolijken]

A number of "please add a feature to exclude apps from update --all" issues have been closed as a duplicate of this one. I'd like to point out that they may be different things. For instance Microsoft Teams updates itself, but does not update the version number. I do not want to pin Teams at an old version, but I do want to exclude it from the all updates.
Another example is that a number of applications are managed by my organisation. I do not want control over which version they should be, I just know that I should not update them myself.

[mdanish-kh]

@vrolijken Please take a look at Package Pinning Types. Your request can be catered by making the pins as Blocking

[norahvii]

I made a python script that doesn't require external libraries to help with this. It seems to work. Feedback appreicated.

[dschulman-repay]

I'm puzzled by the pinning behavior I'm seeing in WinGet 1.6.1573-preview.

Yesterday, a WinGet package for a nightly build of Node.js was released. I'd prefer to wait for an official release, so added a "gating" pin via winget pin add --id=OpenJS.NodeJS --version=20.* --force. That appeared to work:

winget pin list
Name                                            Id                                Version          Source Pin type Pinned version
---------------------------------------------------------------------------------------------------------------------------------
Microsoft 365 Apps for enterprise - en-us       Microsoft.Office                  16.0.16327.20324 winget Pinning
Microsoft Windows Desktop Runtime - 7.0.8 (x64) Microsoft.DotNet.DesktopRuntime.7 7.0.8            winget Pinning
Node.js                                         OpenJS.NodeJS                     20.4.0           winget Gating   20.*

But subsequent calls to winget upgrade produce

Name    Id            Version Available                        Source
---------------------------------------------------------------------
Node.js OpenJS.NodeJS 20.4.0  21.0.0-nightly202307053ca45cf8c7 winget
1 upgrades available.
1 package(s) have version numbers that cannot be determined. Use --include-unknown to see all results.
2 package(s) have pins that prevent upgrade. Use the 'winget pin' command to view and edit pins. Using the --include-pinned argument may show more results.

The issue appears to be that WinGet allows that nightly build to be displayed since its version doesn't match the gating 20.* regex. Which makes sense - but what, if any, mechanism is available for the desired "don't bug me with nightly builds" behavior?

Or am I missing something here?

[florelis]

@dschulman-repay For the specific case of Node.js nightly builds, the nightly builds have been removed from the winget-pkgs repo, so they shouldn't show up anymore. Correct handling of nightly and stable versions would be covered by #147

But the pinning thing is weird. What you expected should have been what happened; gating it to 20.* should have prevented 21.0.0-nightly.... from showing up on winget upgrade. It would still show in winget list, though. winget upgrade shows the latest version winget would try to upgrade to (so it would filter those not matching the pin) but winget list would show the latest available even if it's pinned.

[cobalt2727]

Currently I'm a big fan of the workaround where I just... don't accept the admin prompt for programs I don't want to attempt an update for.

edit: /s

[masterflitzer]

Currently I'm a big fan of the workaround where I just... don't accept the admin prompt for programs I don't want to attempt an update for.

very bad workaround, not every app needs an UAC prompt and the workaround is interactive only, also how can you say big fan when this is a mediocre workaround at best

[maksyms]

Currently I'm a big fan of the workaround where I just... don't accept the admin prompt for programs I don't want to attempt an update for.

This is the only workaround that works for me now. Pinning packages (VC Redistributables) - and yet, on winget upgrade --all, they're still being upgraded.

[MagicAndre1981]

Pinning packages (VC Redistributables) - and yet, on winget upgrade --all, they're still being upgraded.

looks like you missed the --blocking parameter

[maksyms]

@MagicAndre1981 Nope, tried that as well. Note that both --version and --blocking simultaneously are not allowed.

[MagicAndre1981]

winget pin add --id Mozilla.Thunderbird --blocking works for me and prevents the accidentally update from 102.13.0 to 115 which has a new UI which I don't want 🤔 🤷‍♂️

[tawissus]

Is it possible to exclude a current version?
There is currently a problem with RustDesk, for example. An older version is being delivered there (1.2.3 overwrites 1.2.3-1).

[helmesjo]

Just for future reference:
I think, instead of inventing extra flags, that it would be better to pick a syntax that covers it all (so instead of flags, the internal machinery just parse the constraint). See build2 version constraints for an example of something that works very well.

Examples:

==X.Y.Z
>=X.Y.Z
>X.Y.Z
<=X.Y.Z
<X.Y.Z
^X.Y.Z         # X fixed, newer Y & Z (minor & patch) allowed
~X.Y.Z         # X & Y fixed, newer Z (patch) allowed
[X.Y.Z U.W.V]  # range 'from < to'
[X.Y.Z U.W.V)  # range 'from <= to' 

Pinning could still exist, but above scheme would be more in line how the CLI is excepted to work. Looking at other package managers you often want this possibility at the time of install instead of pinning it (which I assume is) globally.