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";
};
