Dependency Providers

[Trenly]

Description of the new feature / enhancement

• Related to Support for "or" dependencies. #1789
• Related to Support alternative dependency #2103

---

The need for "Or" dependencies, sometimes referred to as "One of" or "Any of" has been highlighted before. There are many cases where Package C is dependent on Package A or Package B.

There is another use case where Package C may require something which could be provided by a number of different packages - some which may be unknown to winget or possibly not yet created. A great example of this are packages which require a JRE to be installed. There is the official JRE from Oracle, but there are also many different versions supplied through other vendors, any of which may satisfy the requirement of having a JRE. If a new package is added in the future which also satisfies the requirement of providing a JRE, all manifests using the "One of" dependency style will require updating to include the new package. This necessitates having a way to dynamically specify categories of dependency independent of specific package identifiers.

Proposed technical implementation details

To accomplish this, two new manifest fields could be added under dependencies (or some other way, whatever works)

Dependencies:
  Providers:
     - <From Enum>
  Provides:
     - <From Enum>

Providers would be any group of dependencies which have so many potentially applicable identifiers that it does not make sense to list them individually. Some examples would include LaTex, JRE, JDK, maybe even VSCode (given all the knock offs and customized versions).

The list of Providers and associated Package IDs would need to be available in the PreIndexed source and REST source. This will allow for checking if a provider dependency has been met.

If a user attempts to install a package which is dependent upon Provider A, any PackageID which declares itself as Provides A shall satisfy the dependency.

Usage of Provides in the community repository should throw a validation warning, requiring manual review from Microsoft before being merged. If waivers are used, they should apply only to existing Provides such that if a new value is added, manual validation will be triggered again. Additionally, removal of Provides shall require manual review. If version 3 of the package declares the package as a provider, version 4 must also declare the provides; however, it would be acceptable if version 1 and 2 did not. Given the complexity around dependencies and ensuring accurate providers, it would be best not to use waivers at all for the initial release.

[NotWearingPants]

Relevant excerpt from winget's dependencies spec:

In some cases suitable items may exist in the same source, but for licensing or personal preference, no explicit package should be required. One example is Java. Many vendors offer JREs and JDKs so it may be more reasonable to have a user informed, and allow the user to confirm the presence of a dependency.

I love the solution of "provides", it's much better than each package that needs a JRE having to list all the JRE alternatives in its manifest. If a user tries to install a package that has Providers which are not satisfied, the CLI should list all packages with the matching Provides and let the user choose (using arrow keys + Enter).

[NotWearingPants]

An important aspect of this to consider is depending on versions:

A package might depend on having any JRE, but also may require Java 17.x specifically, or Java >= 17.

Users might install a package that depends on Java 17.x alongside a package that depends on Java 18.x, which requires installing two Java versions side-by-side and configuring PATH correctly (maybe by setting the PATH to different values before each package is ran).

Also note that the version numbering of a Provides entry might be different than the version numbering of packages that provide it, for example the requirement Python >= 3.8 can be satisfied by the package Python.Python.3.8 (CPython) or by GraalPython >= 20.1.0.