Winget-cli: Support for package dependencies

[denelon]

Description of the new feature/enhancement

Some packages like IDEs require the language to be installed separately. Most installers take care of their own dependencies, but there should be a way to support this situation. Maybe it's just a package collection, but we would still need to figure out the right order to install packages like this

Proposed technical implementation details (optional)

[denelon]

https://github.com/microsoft/winget-pkgs/pull/131 is an example of a package that has an external dependency.

[Conan-Kudo]

You should consider using openSUSE/libsolv for this. It's a battle-tested dependency resolver library, used by DNF, Zypper, opkg, mamba, and other package managers.

[adelcast]

Couldn't agree more with @Conan-Kudo. I currently maintain opkg, a tiny package manager used for embedded devices. It used to rely on its own dependency engine, which was the most complicated/buggy code in the project. We added support for libsolv, which smoothed things out a lot (speed them up too, since libsolv is a really fast SAT solver). Now dependency bugs are a tiny fraction of the overall bug backlog.

Another benefit is that by sharing the same dependency model as rpm/dpkg (Recommends, Depends, Suggest, Conflicts, etc) you get a model that has been successful for 20+ years, so there is no need to reinvent the wheel. It will also bring winget closer to other package managers that already have large tooling around them. Some of that tooling could then be leveraged by winget. Certainly an option worth giving some serious thought.

[adamroach]

Another example of a dependency I would expect winget to understand is: powertoys depends on .NET Core being installed, but winget will happily install powertoys in what is effectively an unusable state (since it doesn't install .NET Core automatically).

[dodgepong]

Another example would be any GPL application that depends on VC++ runtimes, such as OBS Studio. The GUI installer for OBS prompts the user to go download the VC++ redists if they are not detected on the machine, but when installed via winget, since the installer is run with the /S flag, that prompt is never shown to the user.

GPL applications are allowed to link against VC++ runtimes via the System Library Exception, but are forbidden from distributing those libraries, or else the exception does not apply.

[denelon]

What are thoughts on a short-term UI display/prompt for dependencies?

Assume package foo needs Java to be installed on the machine. Assume the key in the manifest would be "DependsOn". If the foo manifest had "DependsOn: Java", executing `winget install foo' would fail, but the output could include "Foo depends on Java".

This is far from dependency support, but it might be a helpful step in the right direction.

[dustojnikhummer]

What are thoughts on a short-term UI display/prompt for dependencies?

Assume package foo needs Java to be installed on the machine. Assume the key in the manifest would be "DependsOn". If the foo manifest had "DependsOn: Java", executing `winget install foo' would fail, but the output could include "Foo depends on Java".

This is far from dependency support, but it might be a helpful step in the right direction.

I would prefer what Chocolatey does (I can only speak for Choco as that is what I'm using). Chocolatey asks you if you want to install those dependencies and you can say no. Origin is a good example, It relies on a lot of KB updates so

choco install origin -y

will install Origin and its dependencies automatically.

choco install origin

would ask you for every additional package required.

[aetos382]

If the dependent packages are installed automatically, they must support side-by-side installation.
Manifest repositories also need to provide multiple versions.

[phoerious]

I think dependencies are a crucial part of a successful package manager ecosystem. Currently, most Windows applications are entirely self-contained and package managers are nothing but a more convenient interface for downloading and unpacking the installer EXE or MSI. Though that is generally fine, it is not desirable for several reasons:

• it duplicates libraries
• it duplicates entire applications and application ecosystems
• there is no way to keep bundled dependencies up to date

The first issue may not always be solvable, but at least in some cases, standard libraries may be provided through a separate package of which multiple versions can be installed in parallel. For instance, there could be a Qt 5.12, 5.14, 5.15 package, which can reduce the size of dependent applications by a lot. Guaranteeing binary compatibility across various devices, tool chains (MSVC, GCC, Clang), and versions of Windows is not always easy, but should be doable at least in some cases.

The second issue is particularly annoying in the case of many Unix tools, where each tool ships its own entire GNU ecosystem. I wish I could install Git without yet another version of OpenSSH, GnuPG, a full host of basic /bin utilities, and yet another shitty terminal emulator.

The third issue is a consequence of the first two.

I get it that simply wrapping the standard installer is the easiest and most straight-forward way of implementing a package manager on Windows, but now that we have an official Microsoft package manager, I hope it will find some first-class adoption by application maintainers, so that we can finally start cleaning up the package dependency mess.

[aetos382]

As I commented in #340, to support package dependencies, the repository needs to keep all past versions and not let them be deleted.
And we also need a central repository to host the installer packages along with the manifest.
I think it's difficult to support package dependencies when installer packages are spread out across several servers and not managed under a uniform policy.

[riverar]

EarTrumpet requires the VCLibs framework package (i.e. <PackageDependency Name="Microsoft.VCLibs.140.00" MinVersion="14.0.24123.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />).

Winget cannot install EarTrumpet on clean machines at this time. To mitigate this issue, we'd have to manually plumb in vclibs like it's 1999 and/or make serious changes to our Store/AppInstaller CI. Frankly, it's not worth the effort at this time.

[Witchilich]

Another example is
https://github.com/microsoft/winget-pkgs/pull/1467
It requires DirectX 9.29.1974
https://github.com/microsoft/winget-pkgs/blob/master/manifests/Microsoft/DirectX/9.29.1974.yaml
It should support specific version as dependencies too.