Virtual dependencies

[spenczar]

devcontainer features can depend upon other features with the dependsOn keyword. Features are found and inserted into the dependency graph based on strict equality.

This makes it difficult to write general containers which do not tightly couple to particular feature implementations. To make this more concrete, consider that there are multiple features which provide a Python installation:

• The official Python feature: https://github.com/devcontainers/features/tree/main/src/python
• Python (via mise): https://github.com/RouL/devcontainer-features/blob/main/src/mise-python/README.md
• Another Python: https://github.com/davzucky/devcontainers-features-wolfi/tree/main/src/python
• Hypermodern Python: https://github.com/natescherer/devcontainers-custom-features/blob/main/src/hypermodern-python/README.md

In many (all?) cases, when making a feature that uses Python, any of these would be sufficient as a dependency. But which one to use is not clear.

Linux package managers have long dealt with this problem. Debian's aptitude calls these virtual dependencies, as does Gentoo. Packages list the capabilities they Provide, and those provisions become the thing that downstream packages depend upon.

It is clear that this feature is missing from devcontainers, since the community has started indicating these virtual dependencies by inserting them into feature names. For example, "(via pipx)" appears frequently in the list of features available today; some examples picked at random are aws-sso-util (via pipx) and pre-commit (via pipx). These packages implicitly depend upon pipx; the dependency is not in a dependsOn clause because there are multiple ways that a devcontainer could have pipx installed.

If this isn't addressed, I think it will become a morass of implicit dependencies that makes it difficult to write and use devcontainer features. I'm writing this to try to start discussion:

• Is this a real issue that should be addressed?
• What ways could it be addressed?
• How could existing packages be migrated into a new solution?

[thediveo]

Almost same problem here, but with Go; while there is only a single quasi-standard Go feature, devcontainer users might want to bring in Go via a different way than the Go feature. Also, the way feature configuration parameters are resolved (not really) has even myself caused woe when wanting to install a Go version other than latest, as parallel dependencies might interfere.

At this time, I've moved to soft dependencies using installsAfter which feels like a bad band-aid and clearly documenting the need for feature users to provide Go either through a base image or some feature.