[Spec] First pass at Side-By-Side support.

[denelon]

• I have signed the Contributor License Agreement.
• This pull request is related to an issue.

Related to:

• Better support for Side by Side packages #2129

Possibly related to:

• Winget upgrade lists and installs Python 3 twice (and any time I start the upgrade) #1392
• Uninstall fails when two versions have the same name, and different ID. #1619
• Blender update reports "multiple packages found" #1778
• Winget upgrade shows XNARedist 3.1.10527.0 to be upgraded to 4.0.30901.0, but installation is actually meant to be side-by-side #1831
• Upgrading an application does not remove the existing version #1865
• Attempting to uninstall a specific version of a package doesn't work #1886
• Winget can't find installed package to uninstall #2118
• --include-unknown shows a lower number of packages after running "winget upgrade --all" #2458
• Winget upgrade --all not updating certain packages when reporting updates available #2634
• uninstallAll option for upgrade/install behavior #2645
• [Side-By-Side] List by package identifier fails #2726
• After winget upgrade ImageMagick.ImageMagick, two different versions are installed side-by-side #3069
• winget tries to install new powershell but the version is already installed  #3179
• winget sees 5 upgrades only manages 3 #3229
• Upgrade loop #3248
• winget upgrade Microsoft.VCRedist.2013.x64 most current package missing? #3278
• Python.Python.2 Package v2.7.15150 is in a seemingly corrupt state  #3485
• Winget says package is already installed, when it isn't #3910
• App different versions, same ID, unable to uninstall #3934

---

Microsoft Reviewers: Open in CodeFlow

[denelon]

update for deny upgrade behavior

[mdanish-kh]

Some packages (Microsoft.PowerShell, Microsoft.VisualStudioCode...screenshot attached below) allow side-by-side installations of same versions of different scope. WinGet should be able to disambiguate installed versions based on scope as well and allow users to:

winget uninstall/install/upgrade Microsoft.VisualStudioCode --version <side_by_side_version> --scope machine/user

[denelon]

update comment

[JohnMcPMS]

I updated the "implementation" section of the main issue with a brain dump that includes things beyond SxS but that are generally related to the greater concept of a more complex association graph.

As @mdanish-kh points out, this spec targets SxS versions, but disregards the potential for SxS within the same version, via scope, architecture, etc. This is relevant for any commands that target the installed entity (upgrade, uninstall).

I want to request flexibility here on the UX of the CLI, as we will need to carefully balance adding more data to the index to achieve the winget list goals. On the other side, we will also be relying on the manifest for deeper information but we only want to pull that down as needed, such as winget list <single package ID> to be able to enumerate every version and flavor of installed item.

[denelon]

Locale is the other troublemaker.

I'll work on additional updates to the proposed specification.

During some very early discussions (2019), we were working on the characteristics that would uniquely define an installer within a manifest for a particular version of a package:

• Installer Type (MSIX, MSI, EXE)
• Architecture (x86, x64, ARM, ARM64)
• Target Platform (Desktop, Server)
• Locale (BCP-47 format)
• Scope (User vs. System)

The other concept mentioned in the updated description of the issue was called out as "group package". I've been thinking of that concept in terms of either a virtual package, or a provider concept.

The example for Python is fairly straight forward as there is one logical ISV (independent software vendor)/Publisher. I actually see Java (JRE/JDK) as more complex due to the fact that there could be more than one ISV/Publisher. In the case of dependencies where a package might need some minimum version of a JRE or a JDK, WinGet could potentially detect that the dependency was met by more than one ISV/Publisher. In the case of an install prerequisite (dependency) for another package, it's not obvious how a preference would be specified, or a default should be chosen.

[Trenly]

During some very early discussions (2019), we were working on the characteristics that would uniquely define an installer within a manifest for a particular version of a package:

• Installer Type (MSIX, MSI, EXE)
• Architecture (x86, x64, ARM, ARM64)
• Target Platform (Desktop, Server)
• Locale (BCP-47 format)
• Scope (User vs. System)

I would add that there should likely be a priority order here - where if a user has a specific architecture installed, that should be respected even if the underlying installer type changed. Ideally all of these uniquely defined installers would be present in the manifest, but with many different permutations of install parameters, it's likely that one (or more) could be missing from the definitions. The client should be able to reasonably detect when an available version doesn't have an architecture matching the installed architecture, same with scope and, where possible, locale.

Although, the more I think about it, that is probably more of a related feature than specific to SxS support

[denelon]

Comments/Concerns:

@ImJoakim
@ItzLevvie
@jedieaston
@KaranKad
@mdanish-kh
@OfficialEsco
@quhxl
@russellbanks
@Trenly

[Trenly]

Question on gating pins.

Assume I have the following pin:

Name                   Id                       Version Source Pin type
-----------------------------------------------------------------------
Microsoft .NET SDK 3.1 Microsoft.DotNet.SDK_3.1 3.1.42* winget Gating

If I have these two versions installed -

Name                                                Id                                     Version       Available Source
-------------------------------------------------------------------------------------------------------------------------
Microsoft .NET Core SDK 3.1.426 (x64)               Microsoft.DotNet.SDK.3_1               3.1.426                 winget
Microsoft .NET Core SDK 3.1.426 (x64)               Microsoft.DotNet.SDK.3_1               3.1.456                 winget

Would the behavior still be to not upgrade, even though I have 3.1.456 installed? clearly the 3.1.426 shouldn't be upgraded, but would 3.1.456 be omitted from upgrade?

[denelon]

I'm going to go ahead and close this since we're taking a different approach on how we're slicing up the side-by-side support. I expect @JohnMcPMS will have a PR for part of this work coming soon™️