nixpkgs: Allow passing `{host,build}Platform` directly + Nixpkgs fn docs by roberth · Pull Request #324614 · NixOS/nixpkgs

roberth · 2024-07-04T16:50:42Z

Description of changes

Add hostPlatform and buildPlatform as parameters to the Nixpkgs function.
Document the Nixpkgs function.
Test Nixpkgs initialization

This new interface has already been applied successfully in NixOS. nixos-generate-hardware has been generating the "default" hostPlatform in hardware-configuration.nix for over a year now without much trouble, and with the benefit of not having to specify system (or similar) in nixosSystem anymore.
Furthermore, the hostPlatform option is always defined and reliably produces the host platform for users who don't use the legacy options. This is in contrast to nixpkgs.crossSystem, which is usually not even defined, and nixpkgs.localSystem which is usually the wrong platform to refer to in a config file.

Ideally we'd clean up the nixpkgs.{system,localSystem,crossSystem} options to reduce complexity and confusion. But the interface in Nixpkgs is still based on the old terminology and behavior. By introducing these parameters also in Nixpkgs, the users' experience with NixOS carries over to Nixpkgs as well.

Further simplifications in the code base are now possible, specifically

stage.nix and related files still work with {local,cross}System, and have logic like
```
${if stdenv.hostPlatform == stdenv.buildPlatform
  then "localSystem" else "crossSystem"} = <...>
```
... which is really just
```
hostPlatform = <...>
```
This can now be simplified by refactoring this code to work with {host,build}Platform variables instead.
NixOS can forward its platform options directly to its Nixpkgs call. This pays off when the *[sS]ystem options are removed.

Things done

Add a 👍 reaction to pull requests you find important.

Shawn8901 · 2024-07-04T18:16:50Z

doc/using/as-a-function.chapter.md

Is it intended that this manual link directly targets a version whilst all others in this document target latest? That kind of looks like being unintentional on first view.

Good catch!
I've changed it to latest and gathered up the remaining URLs.

Shawn8901 · 2024-07-05T14:01:24Z

I am not sure where the inconsistency comes from here directly, but possibly its something that could be addressed.

when defining the hostPlatform in the configuration one has to do like

nixpkgs.hostPlatform.system = "x86_64-linux";

But one can also be more specific like

nixpkgs.hostPlatform  = { system = "x86_64-linux"; gcc.arch = "x86-64-v3"; };

(edit: or is that no longer a thing? havent used it for a while?)

whilst we are here passing { hostPlatform = "x86_64-linux"; }, i find it absolut confusing that one time the hostPlatform is a complex object that has a system and on the other variant it is directly defining the system.

And we should possibly try to avoid to use the same "word" for different things/types to no increase the already confusing situation about system vs hostPlatform that get asked from time to time on some community platforms (which to set when and why).
To i highly appreciate that you try to work on that 🙂

Might it be reasonable to pass the same type that is used when defining it in the config itself?

roberth · 2024-07-05T21:10:02Z

A string is shorthand for a { system = theString; } platform attrset, that is correct.

Shorthand notations do add complexity, I agree, but most users the string notation is more than sufficient.
NixOS allows a string, so I feel like rejecting it here would cause at least as much confusion. Or is it just annoyance?
Ultimately it's a problem with lib.systems.elaborate then. It accepts mere strings, so we'd have to add our own check, or factor out the parts that don't convert a string to { system = theString; }.

Might it be reasonable to pass the same type that is used when defining it in the config itself?

What do you mean by "the config", the NixOS config? I think it already does that.

Shawn8901 · 2024-07-05T22:14:55Z

What do you mean by "the config", the NixOS config? I think it already does that.

ah so nixpkgs.hostPlatform.system = "x86_64-linux"; and nixpkgs.hostPlatform = "x86_64-linux"; are equivalent, and i would also be able to pass hostPlatform.system = "x86_64-linux" instead the "short-handed" hostPlatform = "x86_64-linux" ?

If so i missunderstood it before (so that i can pass both), and i would be then fine i guess, tho maybe a hint that its the same in the docs would be nice (tho i am not sure if the as-function.md is the right place, possibly not, maybe a ref in the link list would be nice if there is any doc how *Platform is specified).

~~With the config i meant in either hardware-configuration.nix or configuration.nix, like how nixos-generate-config does generate.~~

, so I feel like rejecting it here would cause at least as much confusion.

~~it its the same, i totally agree that it should not be rejected when passing as argument to the function.~~

edit: okay i saw in the tests, that there is also a *Platform.system = "<some system>";, so i assume that it can both be used 🙂 Might have been better from my side to fully check the diff first and not stop after the markdown document. So i guess the point is clear and fine for me

roberth · 2024-07-05T23:13:29Z

Don't worry about it. Sometimes we don't know what we don't know. Can't overthink all the time.

…ystem This new interface has already been applied successfully in NixOS. `nixos-generate-hardware` has been generating the "default" hostPlatform in `hardware-configuration.nix` for over a year now [without much trouble], and with the benefit of not having to specify `system` (or similar) in `nixosSystem` anymore. Furthermore, the `hostPlatform` option is always defined and reliably produces the host platform for users who don't use the legacy options. This is in contrast to `nixpkgs.crossSystem`, which is usually not even defined, and `nixpkgs.localSystem` which is usually the wrong platform to refer to in a config file. Ideally we'd clean up the `nixpkgs.{system,localSystem,crossSystem}` options to reduce complexity and confusion. But the interface in Nixpkgs is still based on the old terminology and behavior. By introducing these parameters also in Nixpkgs, the users' experience with NixOS carries over to Nixpkgs as well. Further simplifications in the code base are now possible, specifically - stage.nix and related files still work with {local,cross}System, and have logic like ${if stdenv.hostPlatform == stdenv.buildPlatform then "localSystem" else "crossSystem"} = <...> ... which is really just hostPlatform = <...> This can now be simplified by refactoring this code to work with {host,build}Platform variables instead. - NixOS can forward its platform options directly to its Nixpkgs call. This pays off when the `*[sS]ystem` options are removed. [without much trouble]: #237218

roberth · 2024-09-30T10:14:38Z

Trivial rebase

emmamazeky-commits · 2025-10-16T00:21:46Z

web page is not easy done as said

doronbehar

@roberth the changes here LGTM, and I have been using these {host,build}System arguments for a while and I think this can help the confusion found here.

Do you think the merge conflicts could be solved easily and we can merge this?

roberth requested a review from Ericson2314 as a code owner July 4, 2024 16:50

github-actions bot added the 8.has: documentation This PR adds or changes documentation label Jul 4, 2024

Shawn8901 reviewed Jul 4, 2024

View reviewed changes

ofborg bot added 8.has: package (new) This PR adds a new package 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux. labels Jul 4, 2024

roberth force-pushed the add-nixpkgs-function-platform-arguments-and-docs branch from de0c0b6 to d159fca Compare July 4, 2024 20:11

roberth mentioned this pull request Aug 28, 2024

Rename nixosConfigurations to configurations.<system> NixOS/nix#10291

Open

This was referenced Sep 30, 2024

nixpkgs.{system,localSystem,crossSystem} *values* are useless #49765

Open

flake: lib.nixpkgs.mkPkgs #345459

Draft

roberth added 3 commits September 30, 2024 12:13

doc/as-a-function: Edit

eaa3ff4

doc/as-a-function: Command line us of system and crossSystem are ok

4fd048a

roberth force-pushed the add-nixpkgs-function-platform-arguments-and-docs branch from d8c80cb to 4fd048a Compare September 30, 2024 10:13

wegank added the 2.status: merge conflict This PR has merge conflicts with the target branch label Apr 2, 2025

roberth mentioned this pull request Apr 27, 2025

Add Nixpkgs entrypoint lib, <flake>.lib.nixpkgs.configure, (import <nixpkgs>).configure #402298

Open

13 tasks

nixpkgs-ci bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 25, 2025

emmamazeky-commits approved these changes Oct 16, 2025

View reviewed changes

nixpkgs-ci bot added 12.approvals: 1 This PR was reviewed and approved by one person. and removed 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md labels Oct 16, 2025

doronbehar approved these changes Feb 10, 2026

View reviewed changes

nixpkgs-ci bot added 12.approvals: 2 This PR was reviewed and approved by two persons. and removed 12.approvals: 1 This PR was reviewed and approved by one person. labels Feb 10, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

nixpkgs: Allow passing `{host,build}Platform` directly + Nixpkgs fn docs#324614

nixpkgs: Allow passing `{host,build}Platform` directly + Nixpkgs fn docs#324614
roberth wants to merge 3 commits intomasterfrom
add-nixpkgs-function-platform-arguments-and-docs

roberth commented Jul 4, 2024

Uh oh!

Shawn8901 Jul 4, 2024 •

edited

Loading

Uh oh!

roberth Jul 4, 2024

Uh oh!

Shawn8901 commented Jul 5, 2024 •

edited

Loading

Uh oh!

roberth commented Jul 5, 2024

Uh oh!

Shawn8901 commented Jul 5, 2024 •

edited

Loading

Uh oh!

roberth commented Jul 5, 2024

Uh oh!

roberth commented Sep 30, 2024

Uh oh!

emmamazeky-commits commented Oct 16, 2025

Uh oh!

doronbehar left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

roberth commented Jul 4, 2024

Description of changes

Things done

Uh oh!

Shawn8901 Jul 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

roberth Jul 4, 2024

Choose a reason for hiding this comment

Uh oh!

Shawn8901 commented Jul 5, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

roberth commented Jul 5, 2024

Uh oh!

Shawn8901 commented Jul 5, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

roberth commented Jul 5, 2024

Uh oh!

roberth commented Sep 30, 2024

Uh oh!

emmamazeky-commits commented Oct 16, 2025

Uh oh!

doronbehar left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Shawn8901 Jul 4, 2024 •

edited

Loading

Shawn8901 commented Jul 5, 2024 •

edited

Loading

Shawn8901 commented Jul 5, 2024 •

edited

Loading