Transitive dependency resolution

What would you like to be added?

In complex helm charts, some charts added as dependencies can depend on the same chart at different (compatible or incompatible) versions.

For example:

name: chart-A:
  dependencies:
  - name: chart-B
    version: 1.0.0
  - name: chart-C
    version: 1.0.0
  - name: chart-D
    version: 1.0.0

name: chart-B:
  dependencies:
  - name: chart-D
    version: 1.1.0

name: chart-C:
  dependencies:
  - name: chart-D
    version: 2.0.0

In this case, both chart-A and chart-B can be built with chart-D-1.1.0. Instead chart-C needs the templates defined by chart-D in version 2.0.0 and cannot use version 1.1.0 because it's incompatible.

For those cases, helm should provide a resolution strategy and it should be clearly documented.

Since helm chart versions must be valid in semver, helm could support all of the following:

• Select all the needed versions (in the example chart-D-1.1.0 and chart-D-2.0.0)
• raising an error when incompatible versions are requested
• provide all the incompatible versions with the right scope (in the example above, chart-D-1.1.0 for chart-A and chart-B and chart-D-2.0.0 for building chart-C)

Why is this needed?

To support complex helm chart scenarios in which the same dependency (e.g. a common library) is transitively required in multiple versions without creating a dependency hell