nixpkgs module: Clean up platform options

[Ericson2314]

• system is replaced with the more general localSystem

• crossSystem's description mentions localSystem (and vice versa).

Motivation for this change

localSystem is the better name we want to use going forward. It's been around for quite a while, actually.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

---

[Ericson2314]

This would be a fully elaborated platform, and quite large. I could put something minimal too.

[Ericson2314]

Don't need fallback cause I added default one in module.

[dezgeg]

Renaming this breaks nixops.

[Ericson2314]

The ? builtins.currentSystem fallback above is no longer needed. At some future point I'll make this work with an // optionalAttrs (args ? system) { .. } instead.

[Ericson2314]

I put system back as a deprecated parameter for nixops @dezgeg

[Ericson2314]

N.B. local system was added in https://github.com/NixOS/nixpkgs/pull/22575/files, pre 17.09 I believe.

[Ericson2314]

This passes, I'll merge it. If somebody wants me to remove the deprecation part pending further discussion I'll do it.

Oops didn't mean to right that even before @edolstra's comment.

[edolstra]

IMHO a system -> localSystem rename is unnecessary and creates a lot of pain for the vast majority of NixOS users who don't care about cross-compilation. Also, the name localSystem seems suboptimal in a distributed context (e.g. in a NixOps network, it suggests that it's the system type on which NixOps runs, while it's actually the type of the remote system).

[Ericson2314]

@edolstra I've removed the deprecation part for a separate PR.

This isn't just for cross compilation. If you want to do one of

1. Specify alternative libc
2. Specify exact ARM version

or many other such things for native builds it is necessary too.

I choose localSystem without much feedback one way or another a year ago. It's been the name in nixpkgs for 3 releases but probably little used. I wouldn't mind changing it as long as that doesn't slow down what I hope is a deprecation of system.

[Ericson2314]

@edolstra BTW it would be much conceptually better to make one setting always be the run platform, and make the other optional one the build platform for cross, than what we do here (one is always build, the optional one is run), but I didn't want to break the crossSystem interface. Maybe that was a mistake.

[dezgeg]

This isn't just for cross compilation. If you want to do one of 1) Specify alternative libc 2)Specify exact ARM version

Renaming stuff is not at all necessary for doing that. Setting ARM version is already possible by doing nixpkgs.system = "armv6l-linux"; or nixpkgs.system = "armv7l-linux";. And fine-tuning the platform options was already possible a long ago like this:
https://github.com/NixOS/nixpkgs/blob/16.03/nixos/modules/installer/cd-dvd/system-tarball-fuloong2f.nix#L159

what I hope is a deprecation of system.

I consider this a bad idea.

[Ericson2314]

OK my bad with the ARM example. But if we had this, would we have needed to implement that in Nix? It's not like we do the same for i686 i386 sse3 etc.

[Ericson2314]

Also, concretely, there is more in https://github.com/NixOS/nixpkgs/blob/master/lib/systems/default.nix#L20-L46 here than system and platform. We need to allow specifying that stuff in NixOS somehow.

[dezgeg]

OK my bad with the ARM example. But if we had this, would we have needed to implement that in Nix?

Yes we would because the ARM version affects uname -m output and thus what builtins.currentSystem returns.

It's not like we do the same for i686 i386

Yes we do, actually. If you boot with an old enough processor, uname -m will return e.g. i586 which would mean builtins.currentSystem will start returning i586-linux. (So effectively, we don't support such ancient systems).

Also, concretely, there is more in https://github.com/NixOS/nixpkgs/blob/master/lib/systems/default.nix#L20-L46 here than system and platform. We need to allow specifying that stuff in NixOS somehow.

But most people don't have any need to change them from the defaults. The existing interface works just fine for them.

[Ericson2314]

@dezgeg Ok fair point with uname, I didn't know that's what we were following. I'll go add those other x86 ones to the parser for consistency.

Say we leave system. "most people" may not care but some absolutely do so we still need to expose localSystem. What about top level platform? It's not even exposed on NixOS. Should it also continue to be exposed on nixpkgs or is it obscure enough that people can migrate to localSystem.platform? Finally if foo and localSystem.foo are both defined, who wins?

I guess I'll relent and abandon plans to get rid of system, but I'd really hope we can at least get rid of platform. Having too many ways to do things complicates code and leaves the more advanced way less discoverable.

[dtzWill]

It'd be nice if there was a sane way to set localSystem in a NixOS config. My immediate use-case is musl, "surprise!", but at a high-level it's strange to not be able to reasonably set Nixpkgs options from a NixOS configuration.

On the subject, at least my needs would be met by a mechanism to specify part of the configuration-- this has advantages when targeting multiple "systems", instead of what I have to do now: either hardcode x86_64-unknown-linux-musl or do something completely terrible like introducing a map of system -> localSystem.config. I'm not sure about other use cases.

[Ericson2314]

Yeah this no longer deprecates anything, and we have until 18.09 to bike-shed the localSystem name / make other improvements.

[dtzWill]

This is great, thanks!

Few quick questions/comments now that I've started using it:

• Setting localSystem.config = "x86_64-unknown-linux-musl" is not enough, it appears if you want to set config you need to set it in addition to specifying system. Since system can be 100% derived from config this was unexpected, although not a big deal. This becomes slightly more of a problem/mismatch when I realized this also meant that things like localSystem = lib.systems.examples.riscv64 (or any of the examples I think) doesn't work-- that is, elsewhere the unspecified attributes are "inferred" but not here. Is this a known difference, and regardless would it be much work to resolve it?

• system is passed around various places--and a surprising number of places (particularly in NixOS tests) have code like:
  import <nixpkgs> { inherit system; }. or otherwise do things that doesn't consider or allow specifying localSystem. For example build-vms.nix, as seen in this (kludge) commit where I bake in the localSystem.config to use
  As-is the localSystem specified is ignored which is unfortunate since you need to have/build not just the packages for your NixOS system but for ones you don't use in order to test. If localSystem contains important values for correct execution this might break things in surprising ways. Also, it'd probably be good to minimize the number of times the root of a nixpkgs tree is imported?

I'm not sure what the best solution for this is, I'm not sure how reasonable it would be to try to plumb localSystem everywhere or what other options there might be. But just thought I'd share/report to get some discussion going :).

Thanks!

---

On a slightly related note: it'd be "nice" if there was a good way to invoke NixOS tests and other infrastructure with control over localSystem (or crossSystem!). Unfortunately this is probably a large task, especially for things like release.nix which wants to map over system--it'd need to be reworked and it might not work out to be a very smooth transition. Anyway just a thought :).

(it'd be great if Borg could --at least when asked-- do some musl testing, for example. Anyway...)

[Ericson2314]

@dtzWill I fell you on all of those. The long story is I'm waiting to see how #37252 shakes out to better make lib.systems.elaborate and lib.systems.parse* meld with the module system. But I'm happy to take ideas for the short story.