Conversation
|
This one seems to be an issue: You are basically breaking nix run and friends this way. |
zimbatm
force-pushed
the
flake-systems
branch
2 times, most recently
from
aa7acce to
3f505ef
Compare
|
Thanks, the lock file wasn't up to date for some reason. It's working for me now. Another fun thing that this unlocks: |
|
In https://github.com/zimbatm/exp-flake-systems I tried taking the idea even further and introducing it on the flake registry level. Too bad, flake-registry only supports referencing flakes :) |
Can we avoid having to create nix flake show github:/numtide/treefmt/flake-systems \
--override-input systems "github:nix-systems/aarch64-darwin"🧌 |
What if systems is an actual flake, though? {
outputs = _: {
systems = [ "x86_64-linux" ];
};
}However, why not generalize all of this to be a flake-parts module? {
outputs = _: {
flakeModule.systems = [ "x86_64-linux" ];
};
}cc @roberth and cf. hercules-ci/flake-parts#25 |
Not for all combinations, but we might be able to provide common defaults. The real solution would be to add built-in support to Nix itself. |
|
I updated https://github.com/zimbatm/exp-flake-systems to make it an empty flake. You're still supposed to flake-parts is pretty heavy so I try to avoid it on flakes that are designed to be consumed by other flakes |
|
With regards to https://github.com/zimbatm/exp-flake-systems, I'd really like to see a |
|
It's starting to take shape quite nicely. I move the experiment to https://github.com/numtide/flake-systems. |
|
Now it has its own full github org to document the pattern and host common system combos: https://github.com/nix-systems/nix-systems |
This is a new convention that lets consumers of the flake control what systems this flake will be built with. As a consumer you can pass your own list of systems, by overriding the inputs. Eg: ``` inputs.systems.url = "path:./flake.systems.nix"; inputs.systems.flake = false; inputs.treefmt.url = "github:numtide/treefmt"; inputs.treefmt.inputs.follows.systems = "systems"; ``` Invented with the help of bb010g in numtide/flake-utils#84 See <https://github.com/nix-systems/nix-systems>
|
bors merge |
With this change, it becomes possible to modify the list of systems that a flake is using, using only the flake override mechanisms. See <numtide/treefmt#228> and <https://github.com/nix-systems/nix-systems>.
4 participants
This commit introduces a new convention that allows consumers of a flake to control systems the flake is built with.
One of the core issues of flakes is that the list of systems that a flake is evaluated with is internal to the flake. Some projects can technically build with more platforms, but to change this, the user has to fork or submit a patch to change the list. Conversely, as a consumer of a flake, you might not care of evaluating the flake with all of the systems, and that list cannot be reduced.
To work around that issue, we introduce a new convention:
systemsinput exists, it MUST point to a nix file.flake.systems.nix.With this convention in place, consumers of the flake can now override the list of systems using the input "follows" mechanism like so:
Invented with the help of @bb010g in numtide/flake-utils#84