User contributable container features · Issue #8 · devcontainers/spec (original) (raw)

Provide feedback

Appearance settings

Collecting the remaining tasks here.

Required for "self-hosting" built-in features:

Cache feature downloads in the 'persistent folder'. (Discussed a lock-less approach with @joshspicer to that.)
Use baked-in versions initially, but also check for updates. Requires versioning scheme to avoid having old versions of the implementation update to feature versions using newly introduced functionality.

Required for finalizing the devcontainer-features.json:

Revisit include/exclude: These can currently only target the definition id as stored on a Docker image label. (The original definition id is not stored in the devcontainer.json.) Should be investigate reading /etc/os-release to determine compatibility?
Move settings/extensions properties to VS Code-property. Similar to #1.
Remove old properties like buildArg.
Decide on whether using a single env file is good enough or split it up per feature. (Affects layer cache.)
devcontainer features: Dependency Management #16
- How do we handle an inevitable dependency graph?
- eg 1: In the kitchensink image, we'll perhaps want to install node 14 and node 16. How do we specify "installing a feature twice", which one ends up on the $PATH, etc...
- eg 2: Installing two features, where the installation of A depends on installation of B (JupyterLabs and python).
Naming volumes (see here)

User easy-of-adoptability

🏃‍♂️Add variety of starting templates, to complement existing template: https://github.com/microsoft/dev-container-features-template
🏃‍♂️Improve GitHub action to provide additional (linter-esque) feedback? https://github.com/microsoft/publish-dev-container-features-action

Related: #7