Dev Container Meta Feature without install.sh and Feature Equality

[Roemer]

In the process of put the whole development into containers, we found the need for some kind of meta feature.
A simple example:
For go development, we use the official ghcr.io/devcontainers/features/go feature but usually, we want to redirect the download of go packages to our own Artifactory and therefore also set the GOPROXY environment variable.
To add this as a meta feature, I suppose this would look like;

{
    "id": "go",
    "version": "1.0.0",
    "name": "Our Go",
    "description": "Our Go meta package.",
    "dependsOn": {
        "ghcr.io/devcontainers/features/go:1": {}
    },
    "containerEnv": {
        "GOPROXY": "https://repo.ourdomain.com/artifactory/api/go/go"
    }
}

So regarding this, I have two questions:

1. Is is possible to create features without an install.sh file as this is not needed? Currently I just add an empty file for it. Is there a better way?
2. The dependsOn defines a hard dependency to go:1 but I would like to leave that open to the consumer of our go meta package.
   So if the user defines no go package in the devcontainer.json, I should us the latest, if he defines go:1, it should use that version.
   Currently, Feature Equality seems to take into account the version number. So if I have no number in my meta package and version 1 in the devcontainer.json, it will install the go feature twice. Are there ways to get this done nicer? Like just have a hard dependency on a package without any version or options?

If it is unclear, I can clarify this further. Many thanks for any input!

[samruddhikhandale]

Closed accidentally, reopening!

[samruddhikhandale]

Hello! 👋

Thanks for writing a detailed description.

Is is possible to create features without an install.sh file as this is not needed? Currently I just add an empty file for it. Is there a better way?

Unfortunately, currently the spec and the CLI is expecting the presence of install.sh file, else it will throw the following error 👇

chmod: cannot access './install.sh': No such file or directory

we want to redirect the download of go packages to our own Artifactory and therefore also set the GOPROXY environment variable.

How about setting the containerEnv in the devcontainer.json instead? Would that work for you?

The dependsOn defines a hard dependency to go:1 but I would like to leave that open to the consumer of our go meta package.
So if the user defines no go package in the devcontainer.json, I should us the latest, if he defines go:1, it should use that version.
Currently, Feature Equality seems to take into account the version number. So if I have no number in my meta package and version 1 in the devcontainer.json, it will install the go feature twice. Are there ways to get this done nicer? Like just have a hard dependency on a package without any version or options?

Currently, the dependsOn field in the spec does not support version ranges or wildcard versions. It requires a specific version to be specified. This is because each version of a Feature can have different dependencies and installation steps, so it's important to know exactly which version is being used. If you want to allow the user to specify the version of go to use, you could provide different versions of your "Our Go" Feature, each depending on a different version of go. Alternatively, you could make the go Feature an optional dependency, and instruct users to add it to their devcontainer.json file themselves with the desired version.

[Roemer]

Many thanks for your answers!

Unfortunately, currently the spec and the CLI is expecting the presence of install.sh file, else it will throw the following error 👇

Ok, I will add empty install.sh then, or maybe echo a simple Installing ... text.

How about setting the containerEnv in the devcontainer.json instead? Would that work for you?

The point is, we have dozens of teams and dozens of containers and I want to automatically set what is needed via the feature instead of instruct each team to adjust the devcontainer.json file.

Currently, the dependsOn field in the spec does not support version ranges or wildcard versions. It requires a specific version to be specified. This is because each version of a Feature can have different dependencies and installation steps, so it's important to know exactly which version is being used. If you want to allow the user to specify the version of go to use, you could provide different versions of your "Our Go" Feature, each depending on a different version of go. Alternatively, you could make the go Feature an optional dependency, and instruct users to add it to their devcontainer.json file themselves with the desired version.

I see, thanks for the explanation. An optional dependency is defined via installsAfter I suppose? As far as I see, the dependsOn needs the exact version so that it can install that dependency if it is not already in the installation queue. Best for my case would actually be a hard dependency which is actually not installed by my meta-feature but just checked, if it is met (with wildcard versions, maybe even allow ranges like in package.json files) and the build fails, it it is unmet. Pretty much as installsAfter but just fail, if it is unmet.

[Roemer]

I actually found kind of a work-around for hard-dependencies that should not be installed by the meta package:
Check the installation in the meta package's install.sh, so for example with the following script:

if ! [ -x "$(command -v go)" ]; then
  echo 'Error: go is not installed.' >&2
  exit 1
fi