In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
The nixpkgs/nixos version includes a suffix like "pre-git" or
"pre676716.6f16e67b4921", which does not match the conventional
"XX.YY" format of system.stateVersion.
Unifying the format to "XX.YY" allows for (stricter) validation (see #317858),
and the introduction in 3a5ff9a68c was
only concerned with silencing warnings, so the addition of the "pre.*"
suffix into stateVersion was probably unintentional.
Currently there are a bunch of really wacky hacks required to get nixpkgs
path correctly set up under flake configs such that `nix run
nixpkgs#hello` and `nix run -f '<nixpkgs>' hello` hit the nixpkgs that
the system was built with. In particular you have to use specialArgs or
an anonymous module, and everyone has to include this hack in their
own configs.
We can do this for users automatically.
I have tested these manually with a basic config; I don't know if it is
even possible to write a nixos test for it since you can't really get a
string-with-context to yourself unless you are in a flake context.
Some configs rely on being able to pass their own lib argument into
nixosSystem, for instance in order to add their own additional overlay
to nixpkgs.lib.
This was broken by 039f73f134.
We cannot pass `overlays = ...` to `nixpkgs` directly because by default
overlays from `~/.config/nixpkgs` are loaded in there. This doesn't
happen by default, but when using `--impure`.
Explicitly specifying that ignores these overlays. By using `pkgs.extend`
the old behavior can be kept and the new overlay can be applied.
Co-authored-by: Silvan Mosberger <contact@infinisil.com>
* Improves the comments of `lib/flake-version-info.nix` and drops the
`__`-prefix from the filename.
* `lib'` -> `lib0` in `nixpkgs/lib`.
* Drop the declaration of `trivial.version` in the overlay because this
declaration already uses the final expressions of `versionSuffix` and
`release` now.
* No need to fall back to `self.lastModified` anymore, this was a
workaround for pre2.4 Nix.
Co-authored-by: Robert Hensing <robert@roberthensing.nl>
Co-authored-by: Silvan Mosberger <contact@infinisil.com>
A lot of fetchers from Nix's own `libfetchers` also provide the
information that `lib.trivial` aims to expose with
`version`/`versionSuffix`/`revision`. In fact you don't even need a
`nixpkgs` channel to get a proper version suffix because of that!
Unfortunately this isn't used currently. When using the
nixpkgs flake, but not `nixpkgs.lib.nixosSystem` to build a NixOS
configuration, the version will always be `YY.MMpre-git`. One example is
e.g. `colmena` which evaluates configurations via
`import (npkgs.path + "/nixos/lib/eval-config.nix")`.
This patch ensures that the version suffix (i.e. the normalized last
modified date + git revision) is correctly exposed in `lib.trivial`.
Additionally, the change is injected into the following locations:
* `lib`: with that, something like
$ nix eval nixpkgs#lib.trivial.version
23.05.20230921.cf8bf79
is working fine (i.e. rather than `23.05pre-git`).
* `legacyPackages` to make sure that e.g. `legacyPackages.<system>.nixos`
has correct version info. This also applies to everything else using
`pkgs.lib.trivial` for that purpose.
* `overlays.default` which can be applied to a `nixpkgs` and changes the
previous `pkgs.lib` from said `nixpkgs` to also contain the correct
`version`/`revision`/etc..
This is useful for people using `nixpkgs` as flake input, but
importing it manually with
import inputs.nixpkgs { }
Co-authored-by: Linus Heckemann <git@sphalerite.org>
This is mostly equivalent, but `import` was hiding the location
from the module system, breaking error location reporting and
breaking `disabledModules` support for this module (unlikely).
Since the list only gates the platforms the nixpkgs flake exposes
packages to build on, the `hydra` label made little sense. It was also
only used for this purpose, so the `tier*` attributes were largely
unnecessary.
To reflect the intention more accurately, we expose
`lib.systems.flakeExposed` and use it to gate flake.nix's system list.
This happens if the evaluator "loses" the position of an
attr-declaration[1] because of e.g. too many nested function-calls to
build the final attr-set.
While the actual issue should be fixed in Nix itself, this is IMHO a
fair workaround to unblock affected users[2].
[1] e14c245934 (commitcomment-53645936)
[2] It seems as everyone using `divnix/digga` or `flake-utils-plus`
are affected:
* https://github.com/divnix/digga/issues/87
When inlining a module with a problematic declaration, you usually get
get a not-so helpful error like this:
$ cat flake.nix
{
description = "A very basic flake";
inputs.nixpkgs.url = path:../.;
outputs = { self, nixpkgs }: {
nixosConfigurations.foo = nixpkgs.lib.nixosSystem {
system = "x86_64-linux";
modules = [
({ lib, ... }: { services.wrong = 2; })
{ services.nginx.enable = true; }
];
};
};
}
$ nixos-rebuild build --flake .#foo -L
error: The option `services.wrong' does not exist. Definition values:
- In `<unknown-file>': 2
While it's certainly possible to guess where this comes from, this is
IMHO fairly confusing for beginners (and kinda reminds me of the
infamous "infinite recursion at undefined position"-error).
The module-system determines the position of a declaration using the
`_file`-key: this is either `toString path` if `path` is e.g. a value
from `imports = [ ./foo.nix ]` or the file used as `NIXOS_CONFIG` in
`<nixpkgs/nixos>`.
However such a mechanism doesn't exist (yet) for inlined flake modules,
so I tried to implement this in a fairly basic way:
* For non-path declarations, the position of `modules` inside the
`flake.nix` which declares these modules is determined by doing
`unsafeGetAttrPos` on the `modules`-argument of `lib.nixosSystem`.
So the `flake.nix` from above would now raise the following
error-message:
$ nixos-rebuild build --flake .#foo -L
error: The option `services.wrong' does not exist. Definition values:
- In `/nix/store/4vi3nhqjyma73ygs4f93q38qjkhkaxw8-source/flake.nix': 2
Co-authored-by: Cole Helbling <cole.e.helbling@outlook.com>
Co-authored-by: Silvan Mosberger <github@infinisil.com>
Co-authored-by: Robert Hensing <robert@roberthensing.nl>
(The first version of this change, in commit 39fad297fd, broke
`nix-build -A nixosTests.installer.simpleUefiSystemdBoot`. This is the
2nd version, which hopefully does not break anything.)
`nixos-rebuild build-vm-with-bootloader` currently fails with the
default NixOS EFI configuration:
$ cat >configuration.nix <<EOF
{
fileSystems."/".device = "/dev/sda1";
boot.loader.systemd-boot.enable = true;
boot.loader.efi.canTouchEfiVariables = true;
}
EOF
$ nixos-rebuild build-vm-with-bootloader -I nixos-config=$PWD/configuration.nix -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/nixos-20.09.tar.gz
[...]
insmod: ERROR: could not insert module /nix/store/1ibmgfr13r8b6xyn4f0wj115819f359c-linux-5.4.83/lib/modules/5.4.83/kernel/fs/efivarfs/efivarfs.ko.xz: No such device
mount: /sys/firmware/efi/efivars: mount point does not exist.
[ 1.908328] reboot: Power down
builder for '/nix/store/dx2ycclyknvibrskwmii42sgyalagjxa-nixos-boot-disk.drv' failed with exit code 32
[...]
Fix it by setting virtualisation.useEFIBoot = true when needed.
Before:
* release-20.03: successful build, unsuccessful run
* release-20.09 (and master): unsuccessful build
After:
* Successful build and run.
Fixes#107255
When adding `nixpkgs` as flake-input using the `path`-fetcher, you
currently get the following error since neither `lastModifiedDate` nor
`lastModified` are stored in `flake.lock` for paths:
```
error: --- EvalError --------------------------------------------------------------------------- nix-build
at: (48:71) in file: /nix/store/147clg8svaxyj7pl80ra9kmmm72mdg94-source/flake.nix
47| system.nixos.versionSuffix =
48| ".${final.substring 0 8 (self.lastModifiedDate or self.lastModified)}.${self.shortRev or "dirty"}";
| ^
49| system.nixos.revision = final.mkIf (self ? rev) self.rev;
attribute 'lastModified' missing
```
This patch adds the fallback-value `19700101` to `versionSuffix` if none
of `lastModified{,Date}` are set in the lockfile.
This allows you to specify the system-wide flake registry. One use is
to pin 'nixpkgs' to the Nixpkgs version used to build the system:
nix.registry.nixpkgs.flake = nixpkgs;
where 'nixpkgs' is a flake input. This ensures that commands like
$ nix run nixpkgs#hello
pull in a minimum of additional store paths.
You can also use this to redirect flakes, e.g.
nix.registry.nixpkgs.to = {
type = "github";
owner = "my-org";
repo = "my-nixpkgs";
};
