feat(nix): contribute nix devcontainer feature #160
Conversation
| mkdir -p $HOME/.config/nix $HOME/.config/nixpkgs | ||
| echo 'sandbox = false' >> $HOME/.config/nix/nix.conf | ||
| echo '{ allowUnfree = true; }' >> $HOME/.config/nixpkgs/config.nix | ||
| echo '. $HOME/.nix-profile/etc/profile.d/nix.sh' >> $HOME/.bashrc |
There was a problem hiding this comment.
If the user uses any other shell than bash then this would break. Not sure how to resolve - opening PR up for access to review hivemind knowledge.
There was a problem hiding this comment.
Thanks for opening this PR! We've heard a few requests for Nix support, and I agree it could be one of the supported ones in this feature collection.
We also have a self-publishing mechanism available if you want to publish and maintain this nix feature in your own repo: https://github.com/devcontainers/feature-template. We'd love for the community to be able to publish and use features without having to go through a central repo.
| "customizations": { | ||
| "vscode": { | ||
| "extensions": [ | ||
| "bbenoist.Nix" |
There was a problem hiding this comment.
While this is the most popular Nix extension on the VS Code marketplace, it looks like it hasn't been updated since 2015 and the maintainer hasn't responded to several issues recently: https://github.com/bbenoist/vscode-nix. I don't think we should recommend an extension that isn't actively maintained.
| mkdir -p $HOME/.config/nix $HOME/.config/nixpkgs | ||
| echo 'sandbox = false' >> $HOME/.config/nix/nix.conf | ||
| echo '{ allowUnfree = true; }' >> $HOME/.config/nixpkgs/config.nix | ||
| echo '. $HOME/.nix-profile/etc/profile.d/nix.sh' >> $HOME/.bashrc |
There was a problem hiding this comment.
I expect that we'll want these setup in the $HOME of the remoteUser. This is a bit tricky today, and devcontainers/spec#91 is tracking passing in the remoteUser as an environment variable to feature install scripts. It might be simplest to wait for that change to land to keep this feature script simple.
| fi | ||
|
|
||
|
|
||
| sh <(curl -L https://nixos.org/nix/install) --daemon |
There was a problem hiding this comment.
I'm not very familiar with Nix. Do you know if it works well in daemon mode in docker containers? Do we need to add anything to the entrypoint to start the daemon on container startup?
There was a problem hiding this comment.
Yeah an enterpoint would be needed. This I think would also require the container run as root - which isn't a problem for services like Codespaces, GitPod, or when using Docker Desktop, but is a consideration otherwise.
Most of the exploration I did for https://github.com/Chuxel/feature-library/blob/main/src/nix/install.sh was trying to figure out a way to use single user unless the UID/GID changed. I think I have a working model - it sets things up so you can run in either daemon or non-daemon mode (which the nix install script itself couldn't do, but the steps it takes are documented for both scenarios). We could opt to start from here as a baseline if preferrable.
It also verifies the download using their GPG key, has support for referencing a list of packages, a flake, or a derivation.
It also should theoretically work on debian, redhat, and alpine based distros - the main difference is native packages that should be installed and I tweaked the utility functions to do that to detect and install the right one. Something we could do in other cases as well.
| "name": "Nix", | ||
| "documentationURL": "https://github.com/devcontainers/features/tree/main/src/nix", | ||
| "description": "Installs Nix which is a tool that takes a unique approach to package management and system configuration", | ||
| "options": { |
There was a problem hiding this comment.
Would it make sense to have an option for a set of Nix packages to include in the installation? That way the package downloads can be done during an image prebuild to save time later on when users create their dev environment from the image.
|
+1 to exploring our "self publishing mechanism". Our intention is that features in this repo are not treated differently from community features (other than attribution for the author of the feature), given that the author follows the distribution steps we're shared as a specification (https://containers.dev/implementors/features-distribution/). As @jkeech mentioned, we have a template to help bootstrap a features repository (https://github.com/devcontainers/feature-template). Feel free to tag me for feedback if you decide to go down this route. As a plus, you would not need to sign the Microsoft CLA 😛 |
|
Hi @ghuntley, Also, we had CC'ed you in the PR with the changes. We are happy to take any feedbacks. Thanks! |
👋 @Chuxel - https://twitter.com/Chuxel/status/1570582551458369537?s=20&t=Fu1-XS51U969wNmKjP-vwQ
I have signed the Microsoft CLA and surrender all rights and copyright to Microsoft. The intention here is to transfer ownership of this feature layer back to the "Dev Container Spec Maintainers" as nix should be a 1st class citzen.
nb: I haven't tested this works with VSCode devcontainers but the steps are from knowledge I'd taken from my personal docker containers so it should "just work" in theory with minor touchups. Please rework the PR as you see fit to get it over the line.