search

devcontainers / cli

A reference implementation for the specification that can create and configure a dev container from a devcontainer.json.
https://containers.dev
MIT License
1.48k stars 207 forks source link

Features Vendoring #399

Open l0rem1psum opened 1 year ago

l0rem1psum commented 1 year ago

In situations where an internet connection is absent, it will be helpful to download features in advance and later unpack and use it.

l0rem1psum commented 1 year ago

For instance, by using devcontainer features vendor [--vendor-dir] command, features will get downloaded and vendored into .devcontainer/.vendor.

Later on a PC with no internet connection, the devcontainer cli will first try to download features from the internet, and after it has found that there is no connection, it will attempt to read from .devcontainer/.vendor directory for vendored features.

l0rem1psum commented 1 year ago

I'm not sure if this feature will be best proposed as a devcontainer spec or as an implementation feature.

joshspicer commented 1 year ago

This is an interesting one, primarily because individual Features usually need to download assets from the internet when installing.

l0rem1psum commented 1 year ago

This is an interesting one, primarily because individual Features usually need to download assets from the internet when installing.

Thanks for the reply. Sometimes you do still have access to the public network, it is those resources/assets that require private internet access that I usually bundle together with my features. Currently, I'm using oras to help me achieve this so-called "vendoring" feature.

shrcs commented 1 year ago

I currently am facing this offline scenario using the VS code Dev Containers extension. While being offline, using the "Dev Containers: Reopen in container" command will fail during processing the Features with "Failed to parse published versions: Error: getaddrinfo ENOTFOUND"

Would it make sense to also add a related issue on vscode-remote-release repo to handle this situation in the VS code extension and make it operable with referenced Features in offline situations? Or would this fix implicitly be part of this CLI issue?

Please pardon me if this is a silly question ;)

joshspicer commented 9 months ago

@shrcs I wouldn't think resuming an existing dev container would require internet access, is that the situation you're hitting? If the dev container has not previously been created, internet access will required for several points in the creation cycle. I agree vendoring here may help, but likely wouldn't get you all the way from no container -> creation without internet