You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
devcontainer features can depend upon other features with the
dependsOnkeyword. 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:
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
aptitudecalls these virtual dependencies, as does Gentoo. Packages list the capabilities theyProvide, 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
dependsOnclause 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:
Beta Was this translation helpful? Give feedback.
All reactions