Narrow in scope to use more "ecosystem" features and less "package" features

[jcbhmr]

Opened in response to the discussion in #171. This is an issue tracking implementation progress.

---

After some consideration and discussion in #171, I think the scope of this repo should be severely restricted. Sure, lots of other features can be added like Haskell, Heroku's CLI, etc. should all be included... But I don't think we need a jest package if we add a "packages" field of some kind to a generic Node.js feature. This is my opinion.

TL;DR: Make generic ecosystems like Haskell, Python, Node.js, etc. accept arbitrary package installers instead of splintering them into their own features.

{
  "image": "mcr.microsoft.com/devcontainers/universal:linux",
  "features": {
    "ghcr.io/devcontainers-contrib/features/python:1": {
      "packages": ["bikeshed~=3.1.0", "pylint==2.10.0"]
    },
    "ghcr.io/devcontainers-contrib/features/node:1": {
      "packages": {
        "typescript": "^4.8.0",
        "prettier": "latest"
      }
    }
  }
}

See advantages/disadvantages in #171

"Official" statements regarding the goal/scope of container features

Just to clarify, Dockerfiles are still fully supported. It's just more an an advanced use case, and we don't want people to have to be Docker experts in order to start using Devcontainers. We believe that devcontainer features make it easier for people to add and maintain functionality in their configuration and encourage the use of features as a starting point. But if you have a scenario that needs more flexibility/control, you can certainly add a Dockerfile.
-- devcontainers/templates#77 (comment)

Recently, we have modified the "Add devcontainer configuration files" command to make it more simpler and easier to understand. We have updated the Templates and built the dev container config using Features (which avoids the need of Dockerfile in most cases).
-- devcontainers/templates#77 (comment)

FWIW - I would not recommend going to the trouble for basic things that you can do in a Dockerfile like doing apt-get install. RUN apt-get update && apt-get -y install is about as simple as it can get. Features are primarily focused on reusable chunks of config and code that Dockerfiles alone cannot provide.
-- devcontainers/templates#77 (comment)

Tasks

• Start a jcbhmr/devcontainers-contrib-features-172 repo
• Research whether or not objects can be passed to the options of a feature
• Add support to the Node.js feature for a "packages" option of some kind
• Add support to the Python feature for a "packages" option
• Demonstrate real-world implications of this change
• Add documentation describing why this is better/worse and alternatives
• Draw a distinction in user guides between when to use Features and when to use Dockerfiles

[jcbhmr]

After some more research, objects/arrays cannot be passed as part of the options object yet. There is an open issue to add arrays.

devcontainers/spec#57
devcontainers/spec#44 (comment)

In the meantime, the suggestion seems to be to use spaces or commas as delimiters.

[jcbhmr]

@DaneWeber @danielbraun89 I got a test working! 😊🎉 link to repo

[danielbraun89]

Looks awesome! IMO the official python feature should have the same treatment.
One of the reasons I needed the "package" features is the inability to select versions to the default installation utils as can be seen here https://github.com/devcontainers/features/blob/main/src/python/install.sh#L29
I needed for example a way to select mypy to an older version etc I couldnt do that. This approach makes much sense

[danielbraun89]

Looks awesome! IMO the official python feature should have the same treatment. One of the reasons I needed the "package" features is the inability to select versions to the default installation utils as can be seen here https://github.com/devcontainers/features/blob/main/src/python/install.sh#L29 I needed for example a way to select mypy to an older version etc I couldnt do that. This approach makes much sense

NVM saw you already addressed it in https://github.com/devcontainers-contrib/features/discussions/171#discussioncomment-4300704

[eitsupi]

Some notes:

• The comment recommends comma-separation rather than space-separation for arrays. Providing a set of values to a single feature option devcontainers/spec#57 (comment)
• If you would like to deprecate existing Features, I would be happy to discuss it on this issue. How to deprecate a Dev Container Feature in a git repository? (and remove the Feature from the metadata?) devcontainers/spec#155

[jcbhmr]

My opinion on packages being part of features has shifted negatively. It may shift back to positive at some point. Discussion on package installation being a part of features and scope of images vs features vs postCreateCommand in devcontainers-contrib/.github#4

[jcbhmr]

@danielbraun89 I'm closing this open-ended issue in favor of more specific and focused issues. I think this discussion is a good one, but it belongs more in discussions at this point, with issues focusing on concrete tasks instead. (Hence, closing this)