Nix-systems - externally extensible flake systems

Looking for feedback on this nix flake pattern that we found:

7 Likes

I’ve chafed at this a bit myself. I appreciate the value of being explicit, but the ergonomic benefits of flakes don’t mean much when I have to go hoop-jump with booting or sshing into other systems or clone and edit just to be able to try/test/help out a flake that doesn’t specify my platform.

I wish we could handle this as needed for individual inputs just like we’d fiddle follows (and maybe also from the CLI), but this seems like a helpful stopgap in cases where you already need to use the trouble flake as an input.

1 Like

Agreed. This is an issue that I have been talking about for a long time, so I am excited to have found a viable solution. I agree that addressing it in Nix itself would most likely result in even better ergonomics.

5 Likes

What is blocking us from fixing this in Nix directly? It’s been raised so many times and it seems like we’re just refusing to acknowledge the issue. From outside perspective it’s quite frustrating.

4 Likes

I know that for me, it was easy to knock this out in half a day, and I can reap the benefits of it today. Going through the RFC process takes one or two orders of magnitude more time and I don’t enjoy the process.

One difficulty with open-source is that all the efforts are self-directed; we should not ask other people to do things, all we can do is either try to convince them or do it ourselves.

I don’t know; what is blocking you from fixing it? (I’m asking for real, not in jest).

4 Likes

self-directed

On a metalevel, there is a political dimension of joint action, unbound to the RFC process, that can actually be fun.

It just feels like a forest of Ents, sometimes. :deciduous_tree:

So I totally see the conflict.

Maybe the task is furthering resolve among them who hold most agency and timing more than anything else.

1 Like

Why a repo for every system and not a single repo with many branches? Just for having shorter names?

Also you could set up an http server that let you combine several systems e.g.

inputs.systems = {
      url = "https://nix.systems/aarch64_linux/aarch64_darwin";
      type = "file";
      flake = false;
};

But I’m not sure I like it, maybe how you did is better.

I remeber seeing the same hack here. By the way I agree this should be be addressed in Nix directly, but for now, this is probably the best solution we can get without changing Nix itself.

I’ve made a PR a while ago (after others have tried too), but it seems that there’s no consensus that nixpkgs should export a known supported systems helper.

1 Like

The Nix team acknowledges the systems issue, but there hasn’t been a result yet, because we’re prioritizing stabilization of the CLI, as far as implementation work goes - ie besides fixes, docs, testing, DX and contributions.
While the systems issue is to be solved in a CLI component, it has very little contact area with the CLI in general.

If you want to help solving this, we’ve set a direction in the discussion of Extend the flake / cli interface with a function for system-specific attributes · Issue #7709 · NixOS/nix · GitHub

3 Likes

It would be nice if this could somehow include a way to write systems.eachSystem and avoid having to define that in every flake, but I see why that probably doesn’t work.

I’m also curious if this pattern would work better by using a single repo with different branches. To me it seems like it may be a better experience for the user.

Adding a link for visibility to the flake-registry PR proposing including this under the systems name: add systems by zimbatm · Pull Request #42 · NixOS/flake-registry · GitHub

I’m open to trying it. I think it would be longer to type, and also be a bit more opaque to find the list of available systems. Unless it can be combined with the flake registry somehow?