Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pin a package #476

Closed
denelon opened this issue Jul 1, 2020 · 108 comments · Fixed by #2813
Closed

Pin a package #476

denelon opened this issue Jul 1, 2020 · 108 comments · Fixed by #2813
Labels
Experimental This experimental feature can be enabled in settings In-PR Issue related to a PR Issue-Feature This is a feature request for the Windows Package Manager client.
Milestone

Comments

@denelon
Copy link
Contributor

denelon commented Jul 1, 2020

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.

@denelon denelon added the Issue-Feature This is a feature request for the Windows Package Manager client. label Jul 1, 2020
@ghost ghost added the Needs-Triage Issue need to be triaged label Jul 1, 2020
@denelon denelon added this to the Package Manager Backlog milestone Jul 1, 2020
@denelon denelon removed the Needs-Triage Issue need to be triaged label Jul 1, 2020
@megamorf
Copy link

megamorf commented Jul 1, 2020

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
Copy link

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
Copy link

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
Copy link

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
Copy link

Croydon commented Jun 30, 2021

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
Copy link

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
Copy link

Soitora commented Jul 4, 2021

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
Copy link

bchap1n commented Jul 9, 2021

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.

@florelis
Copy link
Member

@dominikjeske

winget pin add --id "Microsoft.WindowsSDK"
I get "No package found matching input criteria."

I think that's a case of us not providing a clear error message. What I imagine is happening is that you have multiple versions of the Windows SDK installed, but winget can only associate one installed app to each package ID, so we don't know which one to pick and return nothing. So it's not "no package found" but rather "multiple installed packages found, and unable to disambiguate". The solution is probably going to be fixing this on the manifests for the Windows SDK to have one ID per version (besides better messaging).

Is there any option for search with wildcards?

No

I looked in docs https://github.com/microsoft/winget-cli/blob/master/doc/specs/%23476%20-%20Package%20Pinning.md but there is no specs for query.

The queries for pinning work the same as for all other winget commands, that is why it's not specified there.

I also noticed that "winget pin list" return onlu partial list of pined packages

Can you share more about the winget pin list only returning a partial list? It's not supposed to, so it may be a bug.

@dominikjeske
Copy link

dominikjeske commented Feb 15, 2023

List looks like below - I have filtered out all Microsoft SDK, Runtime etc. you can see in my previous post but I can't see all pined items

image

@BrianL-STCU
Copy link

@nikolaosginos 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.

@denelon
Copy link
Contributor Author

denelon commented Feb 21, 2023

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

@lackovic
Copy link

lackovic commented Feb 22, 2023

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
Copy link

ksl28 commented Mar 21, 2023

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 denelon added the Experimental This experimental feature can be enabled in settings label Mar 21, 2023
@denelon
Copy link
Contributor Author

denelon commented Mar 21, 2023

@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
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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

@norahvii
Copy link

norahvii commented Jun 9, 2023

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

@dschulman-repay
Copy link

dschulman-repay commented Jul 6, 2023

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
Copy link
Member

@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
Copy link

cobalt2727 commented Jul 16, 2023

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
Copy link

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
Copy link

maksyms commented Jul 22, 2023

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.

image

@MagicAndre1981
Copy link

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

image

looks like you missed the --blocking parameter

@maksyms
Copy link

maksyms commented Jul 24, 2023

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

image

@MagicAndre1981
Copy link

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
Copy link

tawissus commented Apr 6, 2024

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Experimental This experimental feature can be enabled in settings In-PR Issue related to a PR Issue-Feature This is a feature request for the Windows Package Manager client.
Projects
None yet
Development

Successfully merging a pull request may close this issue.