Deuxfleurs/garage

Fork 73

It's not obvious how to use Garage's nix-shell #868

New issue

Open

opened 2024-08-27 15:28:23 +00:00 by withings · 2 comments

withings commented

2024-08-27 15:28:23 +00:00

Contributor

While setting up a Nix environment for Garage (instructions here), the following pops up when trying to spawn a dev shell:

$ nix-shell
error: nix-shell requires a single derivation

Some context:

$ nix -vv --version
nix (Nix) 2.23.3
System type: x86_64-linux
Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux
Features: signed-caches
System configuration file: /etc/nix/nix.conf
User configuration files: /home/me/.config/nix/nix.conf:/etc/xdg/nix/nix.conf
Store directory: /nix/store
State directory: /nix/var/nix
Data directory: /usr/share

I am using the nix.conf file from the repository, with an extra line to enable nix develop (still experimental, but tolerates the multiple derivations).

extra-experimental-features = nix-command flakes

I am not very familiar with Nix, but I believe this is due to the fact that shell.nix defines multiple shell derivations: there's devShell, devShellFull, ci and cache. If I remove all of them but devShell, nix-shell behaves as expected.

Is this something other devs have encountered? Should the documentation be updated to enable/use the experimental Nix CLI, or should shell.nix be simplified to only include the dev environment derivation?

JKR

While setting up a Nix environment for Garage ([instructions here](https://garagehq.deuxfleurs.fr/documentation/development/devenv/)), the following pops up when trying to spawn a dev shell: ``` $ nix-shell error: nix-shell requires a single derivation ``` Some context: ``` $ nix -vv --version nix (Nix) 2.23.3 System type: x86_64-linux Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux Features: signed-caches System configuration file: /etc/nix/nix.conf User configuration files: /home/me/.config/nix/nix.conf:/etc/xdg/nix/nix.conf Store directory: /nix/store State directory: /nix/var/nix Data directory: /usr/share ``` I am using the `nix.conf` file from the repository, with an extra line to enable [`nix develop`](https://nix.dev/manual/nix/2.18/command-ref/new-cli/nix3-develop) (still experimental, but tolerates the multiple derivations). ``` extra-experimental-features = nix-command flakes ``` I am not very familiar with Nix, but I believe this is due to the fact that `shell.nix` defines multiple shell derivations: there's `devShell`, `devShellFull`, `ci` and `cache`. If I remove all of them but `devShell`, `nix-shell` behaves as expected. Is this something other devs have encountered? Should the documentation be updated to enable/use the experimental Nix CLI, or should `shell.nix` be simplified to only include the dev environment derivation? JKR

👀 1

quentin commented

2024-08-29 09:11:32 +00:00

Owner

Hello JKR,

You can select the shell you want with the --attr or -A attribute:

nix-shell --attr devShell - probably the development shell you want
nix-shell --attr devShellFull - similar to devShell with the following additional packages:
- cargo-audit
- cargo-outdated
- cargo-machete
- nixpkgs-fmt
nix-shell --attr ci - used to run our bash integration tests (./script/test-smoke.sh), this shell fetches and make available many famous S3 CLI clients (awscli, winscp, s3cmd, duck, etc.).
nix-shell --attr cache - a maintenance shell to update our nix cache used to speed up builds (for example by caching our cross compilation toolchain).

Hello JKR, You can select the shell you want with the `--attr` or `-A` attribute: - `nix-shell --attr devShell` - probably the development shell you want - `nix-shell --attr devShellFull` - similar to devShell with the following additional packages: - cargo-audit - cargo-outdated - cargo-machete - nixpkgs-fmt - `nix-shell --attr ci` - used to run our bash integration tests (`./script/test-smoke.sh`), this shell fetches and make available many famous S3 CLI clients (awscli, winscp, s3cmd, duck, etc.). - `nix-shell --attr cache` - a maintenance shell to update our nix cache used to speed up builds (for example by caching our cross compilation toolchain).

quentin added the

labels 2024-08-29 09:14:29 +00:00

quentin commented

2024-08-29 09:34:53 +00:00

Owner

Also some context, nix is currently facing some governance challenges, and one aspect of that is that:

the stable nix tools (nix-build, nix-shell, nix-store, etc.) are very permissives in what you can do with them, they are not opinionated / do not provide any convention, and lead to very different usage patterns between project.
so new nix tools were developed (nix build, nix develop, nix flake) that enforce many conventions AND work closer to other language package managers (eg. yarn, composer, cargo, etc.). While flake is still tagged as experimental, it became dominant in some ways/some part of the nix ecosystem. Keeping the new CLI + flake as experimental is often criticized in the light of their real adoption.

With Garage, if there is no clear reason, we want to stay compatible with the "stable" version of the tools we use (we don't rely on rust nightly for example). However, in many cases, nix flakes become the defacto for many nix projects (for example cargo2nix, one of our dependency). I even had to contribute a compatibility patch for cargo2nix to use it with the legacy tools.

Also, nix flake support has been introduced at a later time (by alex I guess) and thus our setup your development environment page is outdated.

So:

legacy nix tools lack conventions, which would require way more documentation on our side
new nix tools have more conventions and thus require less documentation on our side but:
- not everyone is familiar with nix, so at least we need to explain how to install nix
- they require to be activated manually in nix.conf ; or nix must be installed with the Determinate Nix Installer
- the new tools do not have great conventions for our compilation strategy (static compilation with an embedded musl libc)

As a conclusion, I would recommend we update the devenv setup page by:

explaining how to install nix with the determinate installer
a. explain behind a <details></details> tag how to activate the new commands if you have an existing nix install.
document the commands to make a local buid, like:
a. nix build .#amd64
b. nix develop

Additionally, I would recommend we deprecate as much as possible the legacy tooling, so we don't have to support 3 builds systems at once (cargo, legacy nix, nix flake). As part of this deprecation, I think we could also move to the release system I introduced in aerogramme.

Also some context, nix is currently facing some governance challenges, and one aspect of that is that: - the stable nix tools (`nix-build`, `nix-shell`, `nix-store`, etc.) are very permissives in what you can do with them, they are not opinionated / do not provide any convention, and lead to very different usage patterns between project. - so new nix tools were developed (`nix build`, `nix develop`, `nix flake`) that enforce many conventions AND work closer to other language package managers (eg. `yarn`, `composer`, `cargo`, etc.). While flake is still tagged as experimental, it became dominant in some ways/some part of the nix ecosystem. Keeping the new CLI + flake as experimental is often criticized in the light of their real adoption. With Garage, if there is no clear reason, we want to stay compatible with the "stable" version of the tools we use (we don't rely on rust nightly for example). However, in many cases, nix flakes become the defacto for many nix projects (for example cargo2nix, one of our dependency). I even had to contribute a compatibility patch for cargo2nix to use it with the legacy tools. Also, nix flake support has been introduced at a later time (by alex I guess) and thus our [setup your development environment](https://garagehq.deuxfleurs.fr/documentation/development/devenv/) page is outdated. So: - legacy nix tools lack conventions, which would require way more documentation on our side - new nix tools have more conventions and thus require less documentation on our side but: - not everyone is familiar with nix, so at least we need to explain how to install nix - they require to be activated manually in nix.conf ; or nix must be installed with the [Determinate Nix Installer](https://determinate.systems/posts/determinate-nix-installer/) - the new tools do not have great conventions for our compilation strategy (static compilation with an embedded musl libc) As a conclusion, I would recommend we update the [devenv setup](https://garagehq.deuxfleurs.fr/documentation/development/devenv/) page by: 1. explaining how to install nix with the determinate installer a. explain behind a `<details></details>` tag how to activate the new commands if you have an existing nix install. 2. document the commands to make a local buid, like: a. `nix build .#amd64` b. `nix develop` Additionally, I would recommend we deprecate as much as possible the legacy tooling, so we don't have to support 3 builds systems at once (`cargo`, `legacy nix`, `nix flake`). As part of this deprecation, I think we could also move to the release system I introduced in aerogramme.

quentin changed title from ~~Development environment: nix-shell requires a single derivation~~ to It's not obvious how to use Garage's nix-shell

2024-09-02 07:57:52 +00:00

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Deuxfleurs/garage#868

No description provided.