winget-cli
winget-cli copied to clipboard
microsoft
Pin a package
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 https://github.com/microsoft/winget-cli/issues/120#issuecomment-635174060 @rodalpho https://github.com/microsoft/winget-cli/issues/120#issuecomment-635520051 @aetos382 https://github.com/microsoft/winget-cli/issues/120#issuecomment-635741018 @kmindi https://github.com/microsoft/winget-cli/issues/120#issuecomment-637343639
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.
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.
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.
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.
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.
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.
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):
- 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.
- 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.
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.
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.
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.
Same issue here, on a dev host I'm using:
-
nvmfor node version mangement -
pyenvfor python version management
the main issue is that pyenv install python as a program so winget` try to upgrade any versions that is not the expected behaviour.
I'd also need to block updates. I just had audacity try to update to the spyware version.
Yes, we do plan on adding support for pinning packages. We don't have a timeline yet, but I'll go ahead and move it into the v.Next bucket to see if it looks like a good fit for this calendar year or not.
It might be very useful for things like Python, having other apps side-by-side, or avoiding radical changes, like in Python or Postman.
This feature would be useful for people who develop games with Unity and have both a standard and an LTS version installed.
Another field of use would be packages, that are maintained by the companies IT and therefore always fail updating (e.g. Teams, Office); I would love to ignore those explicitly when using the update command. This would not be pinning but ignoring/masking.
Couldn't the same pinning feature be used for those?
ke 20. lokak. 2021 klo 11.08 Philipp Weißmann @.***> kirjoitti:
@brainz80 We've been discussing that with
- #1163
I think pinning might work, but it's a bit of a different scenario in terms of "ignore"/"exclude" this package when running winget upgrade --all.
To be honest with the "ignore this software when updating" I do not really care how the ignoring works. Though I agree: I think pinning is a different topic itself, it probably is related/a "neighbor-feature" to it.
I'd like to not reinstall python 3.7 anytime i upgrade -all as well as just put the name in a file somewhere so i don't have to manually add the exception every time.
I really need this feature. I'm having multiple versions of GhostScript (for debugging). None of them was installed via winget...
GPL Ghostscript ArtifexSoftware.GhostScript 9.50 9.55.0 winget
GPL Ghostscript ArtifexSoftware.GhostScript 9.52 9.55.0 winget
GPL Ghostscript ArtifexSoftware.GhostScript 9.53.0 9.55.0 winget
GPL Ghostscript ArtifexSoftware.GhostScript 9.53.1 9.55.0 winget
GPL Ghostscript ArtifexSoftware.GhostScript 9.53.3 9.55.0 winget
GPL Ghostscript ArtifexSoftware.GhostScript 9.54.0 9.55.0 winget
While I really dig the idea of pinning, I think in the case of Python, it somehow more like a workaround than a solution to the problem. With Python, every minor release (e.g. 3.7, 3.8. 3.9) can be installed side by side. Therefore these versions really ought to be treated as separate applications by Winget (Python 3.8 shouldn't update to 3.10 but to the most recent patch release of version 3.8). I can think of several other applications where this is applicable.
While I really dig the idea of pinning, I think in the case of Python, it somehow more like a workaround than a solution to the problem. With Python, every minor release (e.g. 3.7, 3.8. 3.9) can be installed side by side. Therefore these versions really ought to be treated as separate applications by Winget (Python 3.8 shouldn't update to 3.10 but to the most recent patch release of version 3.8). I can think of several other applications where this is applicable.
+1 Also make sure, that this isn't a publisher think. The end user should be able to set this up as well, in case the publisher didn't
Just adding my name to this as this is a much needed feature. For me it just makes using the update --all option a pain as it installs a bunch of programs that do not need updating.
And ignore list or just simply being able to add a version number in some way would fix this.
Please just add a 👍 to the issue rather than a comment. People are subscribed to these Issues, and they don't need to get an e-mail with a "me too" type of comment. We do use the sort by 👍the backlog to help prioritize features.
Here's my reason why I need this feature:
I'm currently using EdrawSoft.EdrawMax and EdrawSoft.EdrawMind. BUT my installed version is totally different from that in Winget! EdrawMax and EdrawMind stored in winget-pkgs are "international edition" while mine are "Simplified Chinese specified edition" (they called it MindMaster instead of EdrawMind). They aren't the same stuff and license system are different too.
I bought the perpetual license for the Chinese Edition with my QQ account, but have no entrance to login my account in the International Edition (associated e-mail address login failed either). Everytime I invoke winget upgrade --all, Winget will automatically upgrade them from Chinese Edition to International Edition and annoying me.
I've submitted EdrawSoft.EdrawMax.CN and EdrawSoft.MindMaster.CN to Microsoft/winget-pkgs ，but both of them can only be installed in interactive mode and unable to pass the Azure DevOps. The PR is currently at "Draft" state.
So I want to simply pin it and upgrade manually using their own update-checker.
We should also update the output from `winget upgrade" to include a table of pinned packages below the list of upgradable packages and the ones that update themselves.
If anyone wants to rip this apart, please feel free. I think I covered most of the major cases: https://github.com/microsoft/winget-cli/pull/1894
"We should also update the output from `winget upgrade" to include a table of pinned packages below the list of upgradable packages and the ones that update themselves."
Isn't there room to add it beside the rest?
ma 31. tammik. 2022 klo 21.36 denelon @.***> kirjoitti: