Disable a feature with DEVPOD_EXTRA_DEVCONTAINER_PATH

[mathroc]

Hi!

Is it possible to prevent the installation of a feature with a devcontainer override?

I set DEVPOD_EXTRA_DEVCONTAINER_PATH=.devcontainer/devcontainer.override.json

and in it:

{
    "features": {
        "ghcr.io/devcontainers/features/node:1": null
    }
}

but that feature is still getting installed. is it a bug? should I do it differently? or is it not supported?

[skevetter]

Would you provide more details about the workspace configuration and files you are using?

to prevent the installation of a feature with a devcontainer override

Am I understanding this correctly? You have a feature defined in the devcontainer.json. But you are using null in the devcontainer.override.json as a means to disable a feature defined in the devcontainer.json?

If so, what is the reason for not removing (or commenting out) the feature from devcontainer.json.

I have not seen null included in the devcontainer specification. Do you have a reference you could link?

"ghcr.io/devcontainers/features/node:1": null

I believe the design pattern is to define multiple devcontainer user profiles/IDs that have the features you want to use for that profile.

[skevetter]

You can define multiple devcontainer configurations in a repository (see this example). I would imagine the configuration would look something like:

project-root/
├── .git/
├── .devcontainer/
│   ├── python-dev/
│   │   └── devcontainer.json
│   ├── node-dev/
│   │   └── devcontainer.json
│   └── full-stack/
│       └── devcontainer.json

Any reason for not wanting to use this approach?

Products using it should expect to find a devcontainer.json file in one or more of the following locations (in order of precedence):
.devcontainer/devcontainer.json
.devcontainer.json
.devcontainer/<folder>/devcontainer.json (where is a sub-folder, one level deep)
It is valid that these files may exist in more than one location, so consider providing a mechanism for users to select one when appropriate.

https://containers.dev/implementors/spec/#devcontainerjson

Adding explicit ignore is something that I could look at in the future.

[mathroc]

Any reason for not wanting to use this approach?

in my case, the node feature is there not because anybody is doing JS dev (it's all PHP on that project) but because some tools some devs are using need node so the devcontainer.json is 99% the same for everyone, if I start making my own .devcontainer/node-free/devcontainer.json it's going to be annoying to keep in sync with the main one, and could become crowded when people start having their own version for each preferences they have

ideally the node feature wouldn't be in the base devcontainer.json and people would use the override to add it, but the override is only a devpod extensions afaik so people using vscode or something else can't do that

[skevetter]

Ack. And what is the concern with having node installed but not used? Meaning, node is installed in the container and developers can choose or choose not to use node as they wish. Does having it installed harm anything?

[mathroc]

the only concern in my case is avoid waiting the feature to build when the image is building. the base image is updated quite often so it's not that uncommon to have to rebuild the image

ah, and that particular feature has a small bug that makes every shell show an error "rm: cannot remove '/usr/local/share/nvm/current': Permission denied" when they are started, again not a big deal but slightly annoying for something I don't use ^^

[skevetter]

It's up to you, but I pre-build my devcontainer images and deploy the changes through a pipeline. It saves some time.

https://github.com/skevetter/devcontainers