-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nix build --all: build all packages in a flake #7165
Comments
A possible workaround is to add all packages as "checks" and then "nix flake check" will build all. |
Related: #7157 (comment) |
There is also a workaround using |
just ran into the same issue. |
That's what I assumed already existed, at least. Or, when no default package is set, that "nix build" would build everything. |
What should be the output of |
Good question. I guess this would clutter your workspace on larger package sets. |
So it'll basically implicitly create a new derivation using
Resulting in a
I'm not sure I like the approach, as it is non-transparent if Nix is going to build derivations implicitly. It could also be a convention or even a default to make Then it would work without needing a |
I don't like it, shouldn't have to depend on |
What do you think is the better approach to solve the issue?
There could also be a builtin for creating a 'package set', but I would agree is it's not ideal.
Indeed, that's why I thought earlier that it would output Would it output |
I meant multiple outputs per single derivation, so something like |
This seems to be a duplicate of #3811, though I would vote to close the older issue, as there is more discussion in this thread here. The gist of #3811 is that the behavior of For example, the nix repo itself has all these outputs: There's a lot, click here to expand...
As a summary, these are the categories:
Many of them are available for five platforms, but some aren't. What should be built when running As I understand the sentiment of this thread, the general expectation would be for it to build all packages for the current architecture. Potentially, adding the same $ nix build --all # Builds all packages
$ nix build --all packages # Same as above
$ nix build --all packages --all devShells # Build all packages and devShells
$ nix build --all devShells --all-systems # Build all devShells for all systems (requires remote builders)
$ nix build --all --system x86_64-linux --system aarch64-linux # Another flag for selecting specific systems I think A (neat but complex) alternative would be to add more syntax to flakerefs: $ nix build '.#*' # * could be any other character, but has precedent
$ nix build '.#packages.aarch64-darwin.*' # Have to type out system tuple
$ nix build '.#packages.$system.*' # or add special case
$ nix build ".#packages.$(nix system).*" # or additional command and substitute in the shell
$ nix build .#{packages,devShells}.aarch64-darwin."*" # Shell expansion allows more freedom, but also counterintuitive
$ nix build ".#devShells.*.*" # The most niche usecase is the shortest
$ nix build .#packages.{x86_64,aarch64}-{linux,darwin}."*" # And you can do clever stuff like this I'd say the latter approach feels very powerful and composable, but the first one is definitely much easier to discover, and probably covers most use-cases already. They don't have to be mutually exclusive, but more features isn't necessarily better. Another way of solving this could be with nix code, if #5567 ever gets implemented, though that would be far from an intuitive alternative to ProposalI would suggest to start a first implementation with the following behavior:
For starters, the outputs would be numbered results, that is in line with the current behavior of This is obviously a limited and minimally viable solution, but it avoids ambiguity and is relatively easy to implement, which means the feature can be added and maintained with limited effort. It is also easy to extend in the future without breaking backwards compatibility. |
In case it helps, I've made this shell function to build and push all flake inputs and outputs for myself: cashout() {
set -x
nix flake archive --json |
jq -r '.path,(.inputs|to_entries[].value.path)' |
gopass env "env/$1/cachix_auth_token" cachix push "$1"
for target in $(
nix flake show --json --all-systems | jq '
["checks", "packages", "devShells"] as $tops |
$tops[] as $top |
.[$top] |
to_entries[] |
.key as $arch |
.value |
keys[] |
"\($top).\($arch).\(.)"
' | tr -d '"'
); do
nix build --json ".#$target" "${@:2}" |
jq -r '.[].outputs | to_entries[].value' |
gopass env "env/$1/cachix_auth_token" cachix push "$1"
done
} |
what about recurseIntoAttrs ? |
I'm embarrassed to say I don't fully understand how recurseIntoAttrs would be used in this case. Any example would be helpful. |
This is an issue with the new nix commands. Thats also why this issue is open in the nix repository and not nixpkgs.
Now this convention was respected by nix itself: Line 386 in e943ee3
But the problem is that the new command (Reference to the new build command: Line 116 in e943ee3
|
I've added this to devenv: https://devenv.sh/blog/2024/09/11/devenv-11-nested-nix-outputs-using-the-module-system/ |
There's currently no way to build all packages in a flake, a quite common operation that was previously just
nix-build
.You can see here people struggling: https://www.reddit.com/r/NixOS/comments/vohopf/is_there_an_easy_way_to_build_all_the_packages_of/
The text was updated successfully, but these errors were encountered: