Avoid dropping existing features

[alexdima]

From a quick scan, looking at vscode-dev-containers, the following features look like they might be missing:

• homebrew
• fish
• maven
• gradle
• jupyterlab

cc John Keech (@jkeech) Edmundo Gonzalez (@edgonmsft) Christof Marti (@chrmarti)

[samruddhikhandale]

As we want each feature to be capable of running individually but maven and gradle have a strict dependency on Java. There was a discussion of not adding them until we see a need or request from the community. (Apologies if I am not aware of a different discussion)

Installing jupyterlab is bundled with the python feature here, there is an option install_jupyterlab

I can see we are missing homebrew and fish, joshspicer was there a reason for not copying that over? If not, I can add them. 😄

[joshspicer]

homebrew and fish are backed by community-supported scripts. I think we want to encourage the authors of these features to stand up their own community repos, where they can have autonomy over the direction of the feature.

[jkeech]

The main thing we want to be careful about is someone using the old shorthand syntax that then breaks if there's not a devcontainers/features implementation of it. By default, the CLI tooling is expected to automatically map the old shorthand syntax homebrew to devcontainers/features/homebrew.

If we could work with the authors of those community-maintained features to establish a new home for them prior to cutting over to the new repos, then the migration code in the CLI could be updated to have a mapping table that redirects each one to the correct location:

• node -> devcontainers/features/node
• homebrew -> some/repo/homebrew
• fish -> another/repo/fish

Refactoring some features as options of other features is interesting. It would be helpful to see if we have any usage info to know how many users/repos would be impacted by any such feature deprecation/removal. If the usage is very low, it's probably OK to make that change since it sets up a cleaner pattern in the new repo which we can support long-term, and the overall devcontainer "features" concept is still a proposal that does not have guaranteed back-compat support since it's not finalized in the specification.

[alexdima]

If we could work with the authors of those community-maintained features to establish a new home for them prior to cutting over to the new repos, then the migration code in the CLI could be updated to have a mapping table that redirects each one to the correct location

This is a good idea, but doing that automatically might have some undesirable security implications. Current users of homebrew or fish might have added those features thinking they are and will be authored/reviewed by Microsoft. If we redirect those features to another owner automatically, then these users will be surprised to execute features not authored/reviewed by Microsoft.

In general, I believe transfer of ownership is very problematic when it comes to trust. I'd like to suggest that we come up with a deprecation story. That would mean that homebrew, fish or jupyterlab would become deprecated. That could mean they continue to work indefinitely, but only receive critical security updates, and when executed they would show a warning linking to the recommended feature to adopt.

[jkeech]

Current users of homebrew or fish might have added those features thinking they are and will be authored/reviewed by Microsoft. If we redirect those features to another owner automatically, then these users will be surprised to execute features not authored/reviewed by Microsoft.

Great point, I agree.

I'd like to suggest that we come up with a deprecation story.

💯. I'd like us to come up with a way to gracefully deprecate these without having to move them to the new repo. A small tweak on my idea above which handles the transfer of ownership issue would be to keep them in the microsoft/vscode-dev-containers repo as deprecated and publish critical fixes only. Then the mapping in the CLI points the deprecated ones back to the old repo and the non-deprecated ones to the new repo.

[samruddhikhandale]

So we have a plan on dropping homebrew and fish as they are community owned and have security implications. 👍

For jupyterlab, gradle and maven, I believe we are dropping the individual features as they have strict dependencies on Python/Java.

Refactoring some features as options of other features is interesting. It would be helpful to see if we have any usage info to know how many users/repos would be impacted by any such feature deprecation/removal.

However, it does not look like we can completely drop them (without an alternative) as they seem to have moderate usage.

We don't have 💯 data on features usage, but this kusto query shows remote-containers usage which doesn't seem too low. Also, from searching with Blackbird (which searches in public and very few private repos (eg. github)) there is some usage - 4 for maven and 4 for gradle. (Not linking BlackBird results here for the security reasons which I'm not aware of)

Again, we don't have 💯 usage data so I think it's better to provide an alternative because unlike community features we don't have a strong deprecation story and there is some known usage. The alternative (as mentioned in previous comments) is to bundle them as an option with their parent languages. (ie bundling maven and gradle with Java feature as options (Default - false). We already have jupyterlab bundled with python)

As per previous comments, we will have these individual features available in microsoft/vscode-dev-containers repo as deprecated but will show a notifying message that they have been moved to Java/Python as options.

If I can get a 🟢 , then I'll start working on this --> bundling maven and gradle with Java feature as options

[bamurtaugh]

If I can get a 🟢 , then I'll start working on this --> bundling maven and gradle with Java feature as options

This sounds good to me 👍.