Share code between features

[AlexanderLanin]

Motivation

While devcontainers features aim to enable modern software development, the feature code itself is stuck in a lot of code duplication.
For example we can find # Determine the appropriate non-root user 17 times within the features repo. It's the same for me for detecting python version etc etc.

One of the main principles in software development is DRY: Don't Repeat Yourself. That is currently not possible for features!

Proposal

Variant: generic pre-build

Add support for pre-build.sh (in src/_pre_build.sh, src/_pre_build/pre_build.sh, src/_special_cli_stuff/pre_build.sh) which would be executed upon build and feature test calls with an appropriate set of parameters. This way the script can do arbitrary things like copy common code. But it could do even more like downloading common code from yet another source. It could merge code into single files. etc.

Variant: common code

Add support for src/_common which could contain code that is used throughout my features. Build and feature test calls will package that code as well as the install.sh script of the feature. Within install.sh one can simply source/call anything from _common as it's part of the package.

P.S. I wasn't sure whether to put this to cli or spec, please move if incorrect.

[chrmarti]

Or: The devcontainer-feature.json could list relative paths of files and folders that should be copied to the tar file during packaging.

It could be nice if the file structure in the tar file was the same as in the source repository, but currently the devcontainer-feature.json has to be top-level in the tar. Maybe something to think about.

[Chuxel]

I like this suggestion since I think even in devcontainers/features there are common utilities we could have in a utils.sh file that is sourced in install.sh. Right now I think we'd need to setup a CI job to copy files around given how much code is copied between them right now.

FYI on non-root user, #91 is in the CLI and in flight getting released which would allow you to just use a _REMOTE_USER env var. But, there's many other utility functions beyond this one in that repository.

[AlexanderLanin]

19 days have passed and I have a new view on that. That's how fast the software world changes ;-)

Current setup unintentionally allows a powerful reuse of those scripts we have, for example:
curl -s https://raw.githubusercontent.com/devcontainers/features/main/src/python/install.sh | sudo VERSION=3.7 bash

Of course there are a bunch of such install scripts, but generally speaking those that are used for devcontainers are well tested due to ease of testing in different environments.

[joshspicer]

+1 to this. Below is just some spitballing, but an idea i've been tossing around is the concept of library Features. They cannot be referenced directly in a devcontainer.json, but rather a Feature will declare that it depends on a library.

{
 "id": "ruby":,
 "version": "1.2.3", 
 "libraries": [
 "ghcr.io/devcontainers/features/lib:1"
 ]
}

The CLI would then automatically fetch ghcr.io/devcontainers/features/lib:1 and source the contents into the executing install.sh script. These libs would be cached as any other OCI artifact, but allows an author to quickly update "helper functions" for their entire suite of Features.

For the devcontainers maintainers team, we would publish and maintain a ghcr.io/devcontainers/features/lib library Feature that anyone could use. For our own Features in devcontainers/features, it would reduce the size of each install.sh significantly and reduce the copy/paste errors and out-of-sync errors we occasionally see.

[jcbhmr]

Also discussion in https://github.com/orgs/devcontainers/discussions/10 and https://github.com/devcontainers-contrib/features/discussions/83