Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
It creates interoperability issues that can not be reconciled by
`lib` or maintainers of projects that use the Nixpkgs library.
Occasionally, end users may be able to solve the problems they run
into, but most are not prepared to deal with this set of problems,
nor should they be.
Typical conflict:
- User wants to propagate their own lib, because it has some function
they like to use throughout their projects
- Project maintainer requires the project's lib to be used
No sane language uses a single namespace for combining all the things.
(Arguably not even C with its extensive use of prefixing)
Meanwhile, in Nix, all symbols are first class variables. We don't even
have the concept of a global top-level namespace to pour everything into.
With `lib` you can try to approximate that, I get the appeal of its
apparent simplicity, but since `lib` can't be global, we just don't even
get that apparent simplicity.
I apologize for not offering concrete solutions to this in the text.
The manuals are limited to reference documentation.
Alternatives - of which we have multiple - are best provided in
task-oriented documentation, e.g. nix.dev.
nixfmt-rfc-style is built with Haskell, and the packaged GHC compiler
does not support any of these platforms (currently?).
error:
… while checking flake output 'devShells'
at /nix/store/p36amaznf46ic90fb2rw5c952mgj6mfi-source/flake.nix:123:7:
122|
123| devShells = forAllSystems (system: { } // lib.optionalAttrs (system != "armv6l-linux" && system != "riscv64-linux") {
| ^
124| /** A shell to get tooling for Nixpkgs development. See nixpkgs/shell.nix. */
… while checking the derivation 'devShells.x86_64-freebsd.default'
at /nix/store/p36amaznf46ic90fb2rw5c952mgj6mfi-source/flake.nix:125:9:
124| /** A shell to get tooling for Nixpkgs development. See nixpkgs/shell.nix. */
125| default = import ./shell.nix { inherit system; };
| ^
126| });
(stack trace truncated; use '--show-trace' to show the full, detailed trace)
error: Package ‘ghc-9.6.6’ in /nix/store/8akjd9ngyzhzi1412nxmw26rnj93l3gp-source/pkgs/development/compilers/ghc/common-hadrian.nix:579 is not available on the requested hostPlatform:
hostPlatform.config = "x86_64-unknown-freebsd"
package.meta.platforms = [
"aarch64-darwin"
"aarch64-linux"
"i686-linux"
"x86_64-darwin"
"x86_64-linux"
]
package.meta.badPlatforms = [ ]
, refusing to evaluate.
Otherwise, `nix flake check --all-systems --json` fails with:
error:
… while calling the 'head' builtin
at /nix/store/0jy5khqx0rfw8avcq6z5zaxaj2ppz8d3-source/lib/attrsets.nix:1575:11:
1574| || pred here (elemAt values 1) (head values) then
1575| head values
| ^
1576| else
… while evaluating the attribute 'value'
at /nix/store/0jy5khqx0rfw8avcq6z5zaxaj2ppz8d3-source/lib/modules.nix:816:9:
815| in warnDeprecation opt //
816| { value = addErrorContext "while evaluating the option `${showOption loc}':" value;
| ^
817| inherit (res.defsFinal') highestPrio;
… while evaluating the option `system.build.toplevel':
… while evaluating definitions from `/nix/store/0jy5khqx0rfw8avcq6z5zaxaj2ppz8d3-source/nixos/modules/system/activation/top-level.nix':
… while evaluating the option `system.systemBuilderArgs':
… while evaluating definitions from `/nix/store/0jy5khqx0rfw8avcq6z5zaxaj2ppz8d3-source/nixos/modules/system/activation/activatable-system.nix':
… while evaluating the option `system.activationScripts.etc.text':
… while evaluating definitions from `/nix/store/0jy5khqx0rfw8avcq6z5zaxaj2ppz8d3-source/nixos/modules/system/etc/etc-activation.nix':
… while evaluating definitions from `/nix/store/0jy5khqx0rfw8avcq6z5zaxaj2ppz8d3-source/nixos/modules/system/etc/etc.nix':
… while evaluating the option `environment.etc.dbus-1.source':
(stack trace truncated; use '--show-trace' to show the full, detailed trace)
error: cannot bootstrap GHC on this platform ('riscv64-linux' with libc 'defaultLibc')
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
