why you install so many tools via apt?

[dzmitry-lahoda]

nix-devcontainer/src/Dockerfile

Line 20 in 1e36169

RUN apt -y install --no-install-recommends \

[offlinehacker]

As I remember it is because nodejs that vscode server is running in container requires them. Nix has linker and libraries installed on unstandard paths and nodejs binary that vscode server uses does not work with these (at least not without hacks). If you find better solution that does not involve hacks, or if you have seen that some of these are not needed anymore, it's more than welcomed.

[dsyer]

I guess you could also use one of the "standard" base images from Microsoft (e.g. mcr.microsoft.com/vscode/devcontainers/base:0-focal). Probably all you need on top of that is curl and xz-utils to run the nix installer.

[dzmitry-lahoda]

I am in progress right now to do that. We had previos attempt, so nix installation is broken if install nix via nix into MS container.

[offlinehacker]

The thing is I am not too much fan of existing Microsoft images, because they have these custom shell scripts to bootstrap environment and plugins. I think we could have nice portable development containers if Microsoft put more effort, but looks like they did minimal to get job done.

[offlinehacker]

On the second thought, I am not really opposing official Microsoft images that much, so if we can simplify this devcontainer it would be great as well.

[dsyer]

I’m not sure it would simplify it much without sacrificing features, unless (as you say) the base images change a bit. I use the MSFT base images for my experiments because they get me to a nixable container in VSCode relatively quickly, but I don’t need all the extra features here. I was just suggesting it in case the OP wanted to roll their own container.

[dzmitry-lahoda]

ok, seems home-manager approach works. even docker-in-docker works. but only locally. remotely its sucks NixOS/nix#6680

[dzmitry-lahoda]

this PR based on others works ComposableFi/composable#1530

[offlinehacker]

@dzmitry-lahoda If I open this repo https://github.com/xtruder/nix-devcontainer-python-jupyter, that's using nix-devcontainer in github codespaces it works just fine. I don't have any permission issues described here NixOS/nix#6680

[dzmitry-lahoda]

https://github.com/ComposableFi/composable/blob/dz/byog-container/Dockerfile

• so it is official MS based
• minimal apts
• pre baked (so docker file is one liner)
• flake baked
• home-manager baked
• at least Rust Analyzer works, not sure if we will need to Go code as in this repo to fix extensions, hope there are more declarative ways?
• MS derived container features like docker in docker work
• it has some direnv, but not yet tried if it works or like
• I hope to user dockerTools to bake container too, and specifically bake docker without adhoc feature.

[offlinehacker]

@dzmitry-lahoda what do you think would be the best way to go forward, making official nix devcontainer image? I have few additional things included in this image like:

• extension preloader, that will make sure that nix-env-selector is loaded before other extensions (before Extensions startup loading order microsoft/vscode#57481 is implemented in vscode)
• dynamic environment reloading without rebuilding image

What I see is missing is:

• base it on official ms image like you did
• optional integration for home manager (as devcontainer extensions maybe)

You can use flakes with this nix-devcontainer as well. It's not straightforward, as you need to have shell.nix to load flake.nix. I was thinking to switch to https://marketplace.visualstudio.com/items?itemName=mkhl.direnv or integrate into nix-env-selector support for loading flakes directly.

[dzmitry-lahoda]

I think best is microsoft/vscode-dev-containers#947 (comment) - use containerTools with home-manager mounted nix with ability to override and add docker-in-docker as feature. so idea that you already in nix shell when is starts. so really I want just nix develop on start or during build. which what home-manager does. is that will eliminate need nix-env-selector load first?

dynamic environment reloading without rebuilding image.

I do not know. Likely it is good. So I will follow other way. I will install and play with nix-env and usual plugins manually. As I like it I will bake them. I am not good in nix and vscode to reload these. So may be home manager can help?

So you pick either invest into vscode or into nix. I prefer nix. Because I want to use Helix too and produce artifacts with Hydra.

I based my work on https://github.com/jmgilman/dev-container .

Also you may read about official stance from MS about features around nix way vs MS way. Definitely I dislike MS way because it is NOT Composable and represents all 👿 why we pick nix first.

[Chuxel]

I’m not sure it would simplify it much without sacrificing features, unless (as you say) the base images change a bit. I use the MSFT base images for my experiments because they get me to a nixable container in VSCode relatively quickly, but I don’t need all the extra features here. I was just suggesting it in case the OP wanted to roll their own container.

@dsyer What would you like to change about the image?

The thing is I am not too much fan of existing Microsoft images, because they have these custom shell scripts to bootstrap environment and plugins. I think we could have nice portable development containers if Microsoft put more effort, but looks like they did minimal to get job done.

@offlinehacker Happy to take feedback here. Also see devcontainers/features#67 for a discussion of some refactoring being discussed. Part of the goal here is to allow you to pick and choose a bit better in creating your own bases given you can also use just straight debian if preferred.

Also you may read about official stance from MS about features around nix way vs MS way. Definitely I dislike MS way because it is NOT Composable and represents all 👿 why we pick nix first.

@dzmitry-lahoda To be clear, Nix is great! But since not everyone uses Nix, we want to be able to support as many scenarios as possible given everyone has their own personal preferences. Features is a way to enable composability across ecosystems, but infofar as the ecosystem you are using already enables it, that's fantastic. There's no requirement on a specific base image for that very reason, and the goal with devcontainers/spec#18 is also to allow dev container metadata to be added regardless of how images are generated.

[dzmitry-lahoda]

yeah, and nix does not support windows. so if assume windows inheritance with features, than nix is no go.