nixos-generate-config: Fix generated hostPlatform.system #237218
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
While the intent of the code was correct, the system string can not be used in the substituteAll function. See NixOS#237216
github-actions
bot
added
6.topic: nixos
12 tasks
ofborg
bot
added
10.rebuild-darwin: 1-10
10.rebuild-darwin: 1
10.rebuild-linux: 1-10
labels
|
Good detective work, and thanks for the quick fix. Confirmed this resolves the issue I observed. |
tpwrules
approved these changes
Jun 11, 2023
1 task
|
Successfully created backport PR for |
13 tasks
roberth
added a commit
that referenced
this pull request
Jul 4, 2024
…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
added a commit
that referenced
this pull request
Sep 30, 2024
…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
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Oct 11, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Oct 16, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Oct 19, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Oct 20, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Oct 23, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Oct 25, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Oct 27, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Nov 1, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Nov 3, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Nov 3, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Nov 7, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Nov 10, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Nov 15, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Nov 16, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Nov 22, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Nov 27, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Dec 1, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Dec 3, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Dec 4, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Dec 7, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Dec 9, 2024
…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]: NixOS#237218
Shawn8901
pushed a commit
to Shawn8901/nixpkgs
that referenced
this pull request
Dec 11, 2024
…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]: NixOS#237218
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes
While the intent of the code was correct, the system string can not be used in the substituteAll function.
Should fix the issue raised in #228133 (comment)
substituteAllis a terrible function and we need to stop using it / fix it respectively #237216Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)