don't take a system argument in default.nix

[CobaltCause]

Just one system is insufficient for cross compilation, although I'm not sure cross compilation is a concern for fenix.

Either way, nixpkgs' default behavior is good enough, and if callers need to do special things about systems, they can do so by providing an instance of nixpkgs configured the way they need it to be.

Also, I did some archeology and didn't find any specific rationale for the original choices:

• c6eba37
• 3d98d48

[getchoo]

I don't think there's any good reason for this change

if callers need to do special things about systems, they can do so by providing an instance of nixpkgs configured the way they need it to be.

As while this is true, it makes things very tedious. The --system argument will no longer work for example, and it will be much more annoying to build for specific systems on machines that support multiple (i.e., Apple silicon and x86_64/aarch64-darwin).

The only thing this PR does is remove that convenience in order to...save a few characters? 🫤

[CobaltCause]

The only thing this PR does is remove that convenience in order to...save a few characters? 🫤

The goal is to prevent fenix from calling builtins.currentSystem when it doesn't need to. Currently, this change isn't strictly necessary to get that behavior, because nix evaluation is lazy and fenix only uses system to instantiate nixpkgs, which can be overriden. This could be a problem if fenix began reading the system parameter directly elsewhere in its code, though, and that would make for an extra thing to override to avoid referencing builtins.currentSystem.

[CobaltCause]

The --system argument will no longer work for example.

Hmm, I don't think this is true. In my testing, this directly affects the value given by builtins.currentSystem, and does not rely on the nix expression taking arguments taking system:

foo.nix:

{
  pkgs ? import <nixpkgs> {},
}:

{
  foo = builtins.currentSystem;
}

$ nix eval --system foo --impure --expr '(import ./foo.nix {}).foo'
"foo"

This behavior is documented here: https://docs.lix.systems/manual/lix/stable/language/builtin-constants.html#builtins-currentSystem

[getchoo]

Ah TIL. I thought it was always shorthand for --argstr system since I had actually had some issues with it working before

Regardless though, this is still removing convivence in other areas (like importing things directly), straying from (mostly) standard practice, and breaking API compatibility for something that isn't actually an issue right now. If you really want to be proactive about preventing the use of this binding elsewhere, a better solution would probably be to shadow it with a new system binding in a top level let ...; in expression

i.e.

{
  pkgs ? import (getFlake "nixpkgs") { localSystem = { inherit system; }; },
  system ? currentSystem
}:

let
  inherit (pkgs.stdenv.hostPlatform) system;
in