Should implementations "reinstall" a feature that's already in the referenced image?

[Alex Vidal (avidal)]

If a feature id is present in image metadata, and that feature is also present in devcontainer.json, should an implementing tool reinstall it?

My gut says yes. The feature metadata only contains the feature ID and not the options that were specified to install it. For example, if you look at the image config for mcr.microsoft.com/devcontainers/cpp:ubuntu-22.04:

❱ crane config mcr.microsoft.com/devcontainers/cpp:ubuntu-22.04 | gron | grep json\.config | grep devcontainer.metadata

[
  {
    "id": "ghcr.io/devcontainers/features/common-utils:2"
  },
  {
    "id": "ghcr.io/devcontainers/features/git:1"
  },
  {
    "remoteUser": "vscode"
  },
  {
    "id": "ghcr.io/devcontainers/features/git:1"
  },
  {
    "customizations": {
      "vscode": {
        "extensions": [
          "ms-vscode.cpptools",
          "ms-vscode.cmake-tools"
        ]
      }
    },
    "capAdd": [
      "SYS_PTRACE"
    ],
    "securityOpt": [
      "seccomp=unconfined"
    ],
    "remoteUser": "vscode"
  }
]

If a devcontainer.json builds on top of this image and includes the same common-utils:2 or git:1, an implementing tool would have no way of knowing if the options match to avoid a (potentially lengthy) reinstallation.

Perhaps this should be added to the docs?

[Alex Vidal (avidal)]

Just noticed after pretty printing devcontainer.metadata that it already indicates git:1 was installed twice.

[joshspicer]

Today there is no deduplication for Features within the image metadata and Features listed by the user in a devcontainer.json. Not to say that that should be the behavior long-term - it may be a nice optimization to have some deduplication logic in the future. In the in-progress Features dependencies spec we have a concept of "Feature equality" that could possibly be utilized here in the future

[Alex Vidal (avidal)]

Yeah, I see that. I'm working on a devcontainers platform implementation for internal usage at Datadog, which includes an SDK and CLI to build and inspect them. Getting danger close to a fully working implementation and ran into this while I was inspecting image config.

[joshspicer]

It's a good callout, and I agree something that could perhaps be more clear in our documentation