devcontainer features: Dependency Management · Issue #16 · devcontainers/spec (original) (raw)

How do we handle an inevitable dependency graph for features that depend on other features.

Currently we have no deterministic way to install dev container ‘features’, nor do we have any mechanism to indicate dependencies.

The Codespaces team has been looking to author more features and hope to swap over our primary definition to be a composition of ‘features’. Recently we’ve run into instances where it was a problem that feature installation order couldn’t be defined.

Example: Installing two features, where the installation of A depends on installation of B (JupyterLabs cannot be installed without a particular version of python present).

It is important to explore how such dependency relationships are handled moving forward. Since it’s a complicated problem, this may even lead us to wanted to investigate pivoting a bit, utilizing an existing package manager like npm to create the directed dependency graph for us?

The concept of ‘remote features’ is quite different than the idea of packaging of a single set of features, so I want to discuss this further so we have some plan moving forward.

Perhaps someone tangential, but we'll also want this dependency graph to permit multiple "editions" of a feature to be installed:

Example: In the Codespaces base image, we'll want to install node 14 and node 16. How do we specify "installing a feature twice", which one ends up on the $PATH, etc...