Infer devShell deps, provide smaller one

[roberth]

Motivation

For contributors with slow connections, small disks, or high standards, provide a smaller shell.

Uses carousel pattern with overrideAttrs/passthru (easy to apply locally, single fixpoint) but that could be refactored to work differently, e.g. package function arguments.
Usage:

nix develop .#native-clangStdenv.small

This makes the packages simpler, but loses a tiny little bit in eval laziness by having to evaluate all components to figure out the devShell, instead of just the ones listed. Not significant.

Context

• Would benefit asymptotically, but possibly not significantly from lib.linkedLists: init nixpkgs#452088
• The helpers seem upstreamable into Nixpkgs lib (like I've done for the cross rename helpers)

---

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[Ericson2314]

Thank you so much, @roberth! This is the exact sort of thing I was hoping for during the meeting. Glad you understood me.

I will leave this up a bit for the others to see also, but I hope we can merge it very soon.

[Mic92]

Can we document this? Also which devshell do we want to recommend here?

[Ericson2314]

Can we document this?

FWIW ultimately I hope the functionality can go in Nixpkgs, as I think better multi-package dev shells is a very useful thing I've wanted there for years.

[roberth]

Can we document this?

So far I treat this as an internal refactor that adds an unimportant .small devShell feature and some new knobs for generic devShell machinery that should go into Nixpkgs at some point.

Also which devshell do we want to recommend here?

The usual one. The .small is for picky users who dig through code and care a lot about closure size ;)

can go in Nixpkgs

• lib.lists: add uniqueByString nixpkgs#459228
• lib.buildInputsClosureCond: init nixpkgs#465394
• Rest is TBD
  • I don't feel we've sufficiently validated even buildInputsClosureCond
  • other parts need generalization to be useful for other projects.

[Ericson2314]

other parts need generalization to be useful for other projects.

I think the way it should work is that the shell would generate the root meson.build with all the subprojects, so subprojects are opt-in rather than opt-out.

For me a very good sign is if one can use the hypothetical generalized version to easily also develop on Hydra at the same time, and skip building nix just because hydra depends on it.

[Ericson2314]

Fixed the two things that @xokdvium found