Handle Multiple Major Versions of One Package #794

cotsuka · 2021-03-12T07:18:53Z

cotsuka
Mar 12, 2021

Brief description of your issue

winget is not able to handle the situation where there are multiple versions of the same package installed, based on name. An example of this in action are .NET runtimes, where you often have multiple major versions installed side-by-side.

Steps to reproduce

Have .NET Core Runtime 3 and .NET Core Runtime 5 installed.
Run winget upgrade --all

Expected behavior

Ideally, I expect .NET Core Runtime 3 to be considered separate from .NET Core Runtime 5. When winget checks for upgrades, it should only look for upgrades relating to that major version.

Actual behavior

winget is seeing both .NET Core Runtime 3 (version 3.1.11.29516 on my computer) and .NET Core Runtime 5 (version 5.0.3.29723 on my computer) and reporting that an upgrade to version 5.0.4.29817 is available for both runtimes.

winget upgrade:

Name              Id                      Version      Available   Source
-------------------------------------------------------------------------
.NET Core Runtime Microsoft.dotnetRuntime 5.0.3.29723  5.0.4.29817 winget
.NET Core Runtime Microsoft.dotnetRuntime 3.1.11.29516 5.0.4.29817 winget

winget upgrade --all:

Found .NET Core Runtime [Microsoft.dotnetRuntime]
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 https://download.visualstudio.microsoft.com/download/pr/7a5d15ae-0487-428d-8262-2824279ccc00/6a10ce9e632bce818ce6698d9e9faf39/windowsdesktop-runtime-5.0.4-win-x64.exe
  ██████████████████████████████  52.2 MB / 52.2 MB
Successfully verified installer hash
Starting package install...
Successfully installed

Found .NET Core Runtime [Microsoft.dotnetRuntime]
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 https://download.visualstudio.microsoft.com/download/pr/c6541c87-42f2-4c5d-b6db-2df0dade5e00/13e89a5fec3ddb224cd93dd18b0761ff/windowsdesktop-runtime-5.0.3-win-x64.exe
  ██████████████████████████████  52.4 MB / 52.4 MB
Successfully verified installer hash
Starting package install...
Installer failed with exit code: 1638

Environment

Windows Package Manager v0.2.10191 Preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19042.867
Package: Microsoft.DesktopAppInstaller v1.11.10191.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

Links
--------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget

denelon · 2021-03-12T17:44:11Z

denelon
Mar 12, 2021
Maintainer

This is something we've been considering for programming languages as well. These may need to be treated as separate packages rather than the same package.

0 replies

denelon · 2021-03-12T17:45:06Z

denelon
Mar 12, 2021
Maintainer

I'm going to convert this to a discussion for now.

0 replies

MattBDev · 2021-03-12T21:40:33Z

MattBDev
Mar 12, 2021

Java is an example where it would be useful to treat each major version as separate packages rather than the same package. The current Java LTS is Java 11, but the latest Java release is Java 15 (soon to be 16). I installed AdoptOpenJDK with winget to get Java 11 but each time I check to see if my programs are outdated it tells me the latest version is AdoptOpenJDK 15.x even if AdoptOpenJDK 11.x got a recent security update.

It is also possible that people who want to use an LTS release of some type of software or programming language may want to update to the newest LTS when it becomes available. It may be worth having an LTS package that will update people from the previous LTS to the newest.

0 replies

cotsuka · 2021-03-14T23:35:53Z

cotsuka
Mar 14, 2021
Author

Python is an example where minor versions also matter: 3.8 vs. 3.9. Could be something like: if you winget install Microsoft.dotnetRuntime you'll always get the highest version possible, including when running upgrade. If you install a specific major or minor version, the package will be pinned to that version. winget install Microsoft.dontnetRuntime-3.0 will only install 3.0.x version numbers.

2 replies

denelon Mar 15, 2021
Maintainer

We do have pinning on the backlog as well as a feature to improve how versioning works with install. Something like winget install Python.Python 3.8.x -pin 3.8.x. The idea is that in the future when the user executes upgrade, they wouldn't be taken past 3.8.x. We also need to take into account this behavior for import and export.

Pd69bq Oct 28, 2021

We do have pinning on the backlog as well as a feature to improve how versioning works with install. Something like winget install Python.Python 3.8.x -pin 3.8.x. The idea is that in the future when the user executes upgrade, they wouldn't be taken past 3.8.x. We also need to take into account this behavior for import and export.

well, brew made separated formulas for each major releases like [email protected], [email protected], [email protected], and maybe you should learn or just simply borrow this solution. keeping and upgrading different branches at the same time is an important feature and as a package manager, this is a serious design flaw of winget tbh

rollingmoai · 2022-07-19T03:28:37Z

rollingmoai
Jul 19, 2022

Any update on this? I have multiple versions of python, and it is annoying to not be able to update them.

7 replies

jedieaston Jul 19, 2022

I was holding on fixing this hoping that pinning was going to resolve it (if you could pin multiple versions simultaneously then you could just do winget install Python.Python.3 --version 3.9 --pin ; winget install Python.Python.3 --version 3.8 --pin or something and have winget not interfere when doing upgrades). If that's not happening as part of the initial pinning implementation then I can start splitting them out into different identifiers based on minor versions.

denelon Jul 19, 2022
Maintainer

I don't think pinning multiple "side by side" versions of the same "package" would work well. There are plenty of strange behaviors and I haven't been able to figure out a way that wouldn't cause confusion. By having the major.minor versions each minor version could be pinned as a unique package.

rollingmoai Jul 20, 2022

Meanwhile, I should still be able to download the latest major version by specifying Python.Python.3. So, for example, currently, Python.Python.3 should download Python.Python.3.10. Or maybe even Python.Python downloading Python.Python.3.

jedieaston Jul 20, 2022

We could maybe accomplish that via a pointer package when those are implemented, so Python.Python.3 always points to the latest major.minor.

sitiom Feb 4, 2023

Meanwhile, I should still be able to download the latest major version by specifying Python.Python.3. So, for example, currently, Python.Python.3 should download Python.Python.3.10. Or maybe even Python.Python downloading Python.Python.3.

Support redirecting manifests #1899

scarlettekk · 2023-01-23T18:08:40Z

scarlettekk
Jan 23, 2023

Sorry to necropost, but has any resolution been reached for this? I can't use winget upgrade --all, because it will always screw up my .NET desktop runtimes (I have 3,5,6,7 installed, and it will variously try to mix and match major versions in uncomfortable and unexpected ways). Trying to winget install Microsoft.DotNet.Runtime.6 while Microsoft.DotNet.Runtime.7 is installed fails similarly.

4 replies

denelon Jan 23, 2023
Maintainer

We're still working on it. There are several different "classes" of challenges here.

There are likely multiple Issues already created for each of them due to the way they present themselves.

Do you have multiple minor versions of the runtimes, or just the latest of each installed?
Are these all the "Microsoft.DotNet.Runtime.*" or does it also include "Microsoft.DotNet.DesktopRuntime.*"?
Do you have more than one architecture of any of them? (x86, x64, etc.)

scarlettekk Jan 23, 2023

I have just the latest of each major version installed They are all Microsoft.DotNet.DesktopRuntime, sorry for the previous incorrectness. All are amd64. I ended up just installing version 7 and waiting to "find out" what needs an older version the hard way.

denelon Jan 23, 2023
Maintainer

Thanks for the details, and no worries. Runtimes are a bit tricky when there isn't a good way to determine which applications might be using them.

scarlettekk Jan 23, 2023

Indeed. The one thing that I miss most from Linux is the simple dependency management. I hope Winget can grow to be truly a ubiquitous windows package manager

jaredlander · 2023-05-18T20:18:16Z

jaredlander
May 18, 2023

Similar to the Python scenario, I am trying to install multiple versions of R. However, a newer version uninstalls the previous, even if I specify different install locations like such.

winget install -e --id RProject.R -v 4.2.2 --location C:\Users\JaredLander\Documents\R\R-4.2.2
winget install -e --id RProject.R -v 4.3.0 --location C:\Users\JaredLander\Documents\R\R-4.3.0

I even tried the --no-upgrade argument, but then I get this message

winget install -e --id RProject.R -v 4.3.0 --location C:\Users\JaredLander\Documents\R\R-4.3.0 --no-upgrade

A package version is already installed. Installation cancelled.

But then I found --force in combination with --no-upgrade and that worked!

winget install -e --id RProject.R -v 4.3.0 --location C:\Users\JaredLander\Documents\R\R-4.3.0 --no-upgrade --force

0 replies

SamHerts · 2023-07-20T17:31:56Z

SamHerts
Jul 20, 2023

I was able to install multiple python versions using @jaredlander suggestion of --no-upgrade and --force

I need Python 3.9 and Python 3.11, so the command I used was:
winget install -e --id Python.Python.3.9 --location 'C:\Users\$Env:UserName\AppData\Local\Programs\Python\Python39' --no-upgrade --force

and:

winget install -e --id Python.Python.3.11 --location 'C:\Users\$Env:UserName\AppData\Local\Programs\Python\Python311' --no-upgrade --force

1 reply

SamHerts Jul 20, 2023

The only issue with this, is winget gets fussy about the actual ID of the package installed, depending on which command was run first.

As can be seen, the version listed of Python 3.11 is > 3.9.13

However, running the python 3.11 executable displays version 3.11 properly. So this installation method works, but winget doesn't like it

tarper24 · 2023-09-26T20:01:37Z

tarper24
Sep 26, 2023

I'm not sure what the latest status of an official resolution is, but I wanted to switch my Python installs management to be handled with winget and came across this thread.

Using the above suggestions, winget install -e --no-upgrade --force --id Python.Python.3.X along with pinning each version after install, winget pin add --id Python.Python.3.X -e -v 3.X.* I was able to get Python 3.8 through 3.12 installed with winget recognizing the versions and packages correctly.

I'm unsure if the pinning was necessary, but it seemed like a good way to prevent old versions getting updated incorrectly.

4 replies

gsevla Apr 10, 2024

clever! but in python's case I think it's not required to pin. In fact, I guess pin isn't even the tool to achieve the behavior proposed here.

e.g: nodejs's lts id is OpenJS.NodeJS.LTS and It's versions can be found by using something like winget search --id OpenJS.NodeJS.LTS -e --versions.

now if I pin version 16 with winget pin add --id OpenJS.NodeJS.LTS -e --version 16.*.*. I can't just pin version 18 because OpenJS.NodeJS.LTS already pinned.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Handle Multiple Major Versions of One Package #794

{{title}}

Replies: 9 comments 18 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Handle Multiple Major Versions of One Package #794

Brief description of your issue

Steps to reproduce

Expected behavior

Actual behavior

Environment

Replies: 9 comments · 18 replies

denelon Mar 12, 2021 Maintainer

denelon Mar 12, 2021 Maintainer

cotsuka Mar 14, 2021 Author

denelon Mar 15, 2021 Maintainer

denelon Jul 19, 2022 Maintainer

denelon Jan 23, 2023 Maintainer

denelon Jan 23, 2023 Maintainer

Replies: 9 comments 18 replies

denelon
Mar 12, 2021
Maintainer

denelon
Mar 12, 2021
Maintainer

cotsuka
Mar 14, 2021
Author

denelon Mar 15, 2021
Maintainer

denelon Jul 19, 2022
Maintainer

denelon Jan 23, 2023
Maintainer

denelon Jan 23, 2023
Maintainer