There are a number of different syntaxes used for attrset type
signatures in our doc strings, this change standardises upon one that
uses :: for specifying attribute type, and ; terminators to be
consistent with nix syntax. There are no bugs in the functions
themselves, just that different syntaxes may confuse new users.
By allowing null, we allow code to avoid filterAttrs, improving
laziness in real world use cases.
Specifically, this strategy prevents infinite recursion errors,
performance issues and possibly other errors that are unrelated to
the user's code.
There is no "aarch64" CPU family — it counts as "arm", as can be seen
from the definition of isAarch64 above.
Checked that stdenv.hostPlatform.isEfi is still true on aarch64-linux.
In the past, most (if not all) armv8 CPUs could also execute armv7. However,
with the advent of Apple Silicon, aarch64 CPUs without any aarch32 capabilities
are now wide-spread among users.
This makes bisecting nix a bit easier.
Example reproducer, invoked from nix directory:
```bash
nix-build ../nixpkgs/lib/tests/release.nix --arg nix '(builtins.getFlake "git+file://${toString ./.}").packages.x86_64-linux.default'
```
`hasUnsupportedPlatform` was not updated with #37395, so it does not
understand attrsets in `meta.[bad]platforms`. In particular,
attrsets in `meta.badPlatforms` will "fail open" and be ignored.
Let's use `lib.meta.availableOn` instead of duplicating its logic.
Thanks to @alyssais for [noticing][1].
[1][https://github.com/NixOS/nixpkgs/pull/194148#discussion_r990817610]
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
When "-n" is generated by the property tests, it causes `echo` to not
output the string since it's interpreted as an option. Apparently
there's no good way to print "-n" with `echo` [1], so switching to
`printf` instead
[1]: https://unix.stackexchange.com/questions/85846/how-can-i-print-n-with-echo
unfortunately we can't unconditionally make this text markdown without
impacting downstream users of docs generation (as noted in #175586).
hide it entirely until the transition is complete.
mkAliasOptionModule should not default to mdDoc descriptions because
that can break out-of-tree users of documentation infrastructure. add an
explicitly-MD variant for now, to be removed some time after the MD
transition is complete.
Adds initial work towards a `lib.path` library
Originally proposed in https://github.com/NixOS/nixpkgs/pull/200718, but has
since gone through some revisions
Co-Authored-By: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-Authored-By: Robert Hensing <robert@roberthensing.nl>
Cross-compilation of anything downstream of gtk3 requires qemu (due to
gobject-introspection) with --target-list=*-linux-user. Without this commit,
those qemu builds will fail on a powerpc64le host due to qemu being configured
with --cpu=powerpc64le instead of --cpu=ppc64le. Unfortunately the build
failure message from qemu in this situation is extremely cryptic.
The root cause turns out not to be the qemu expression, but rather the fact that
on powerpc64le hostPlatform.uname.processor returns the gnu-name (powerpc64le)
for the cpu instead of the linux-name (ppc64le) for the cpu.
uname.processor on mips64el also needs adjustment -- the Linux-name is "mips64"
for both big and little endian (unlike powerpc64, where the Linux-name includes
a "le" suffix):
```
nix@oak:/tmp$ uname -m; lscpu | head -n2
mips64
Architecture: mips64
Byte Order: Little Endian
```
uname.processor on powerpc32 has also been adjusted.
The new derivation should evaluate only if the old derivation does.
Sadly this means that the old derivation cannot depend on the new one
any more, which was used by xorgserver on Darwin. But this is not a
problem as `overrideAttrs` can (and should) usually be used instead.
This change allowed catching an invalid `meta.platforms` in the linux_rpi
kernels, which use `overrideDerivation`.
In the current implementation of Nix, this list would be allocated
over and over. Iirc pennae tried to optimize static list allocation,
but gained no significant performance improvement.
Yes, this function name is inconveniently long, but it is important
for the name to explicitly reference the function and not be mistaken
for the implicit string conversions, which only happen for a smaller
set of values.
If all the docs are auto-generated, it should be easier to convert
them to Commonmark.
Co-Authored-By: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-Authored-By: Silvan Mosberger <contact@infinisil.com>
Render un`_type`d defaults and examples as `literalExpression`s using
`lib.generators.toPretty` so that consumers don't have to reinvent Nix
pretty-printing. `renderOptionValue` is kept internal for now intentionally.
Make `toPretty` print floats as valid Nix values (without a tilde).
Get rid of the now-obsolete `substSpecial` function.
Move towards disallowing evaluation of packages in the manual by
raising a warning on `pkgs.foo.{outPath,drvPath}`; later, this should
throw an error. Instead, module authors should use `literalExpression`
and `mkPackageOption`.
With the goal of making `toPretty` suitable for rendering option
values, render derivations as `<derivation foo-1.0>` instead of
`<derivation /nix/store/…-foo-1.0.drv>`.
This is to avoid causing sudden evaluation errors for out-of-tree
projects that have options with `default = pkgs.someUnfreePackage;` and
no `defaultText`.
Add a section on ordering option definitions.
Also mention `mkDefault` in the section on `mkOverride`.
Clarify the code a bit by renaming `defaultPriority` to
`defaultOverridePriority` and introducing `defaultOrderPriority`.
Add trace items that provide context for a failed definition that
can not be caught within the Nix language.
This also adds a test for the `tryEval` behavior of `showDefs`.
There's no need to use `unsafeDiscardStringContext` since
ee7fe64c0a
(Nix 1.8).
Also the separator can't have a context since `builtins.split` would fail, so
we can assume it doesn't.
This reverts commit b67ee6e861.
https://github.com/NixOS/nixpkgs/issues/202244
error: a string that refers to a store path cannot be appended to a path, at /etc/nixos/nix/nixos-unstable/lib/sources.nix:193:30
appears to happen when there's a nixpkgs git submodule
> So one of the things that is different for a git submodule is that the .git folder isn't a folder, it's a textfile that contains (in my case) this:
> $ cat nix/nixos-unstable/.git
> gitdir: ../../.git/modules/nixpkgs
so that it doesn't make the manual build fail
> Apparently this is related to the combination of this new function not getting exported from the file, while still getting documented.
The main purpose of this PR is to make the basis for
`mkSkeletonFromList`'s decision between `cpu-kernel-libcabi` vs
`cpu-vendor-os` clear, without changing its behavior. The existing
code obscures this decision behind a sequence of prioritized matches
(i.e. `if-then`) which jump around between different coordinates.
Two side benefits of this PR:
1. It makes the root cause of #165836 obvious: we are missing a case
for `cpu-vendor-libcabi`. This is why nixpkgs stumbles over
`*-none-*`.
2. It illuminates some very weird corner cases in the existing
logic, like `*-${vendor}-ghcjs` overriding the `vendor` field,
and `mingw32` being transformed into `windows` in some cases.
Co-authored-by: John Ericson <git@JohnEricson.me>
This requires us to avoid the `tryEval` + `throw` combination,
because throw is strict in its error message, and we don't want
to drop our single clue when `commitIdFromGitRepo` is used
incorrectly.
It gives a warning on the lazy-trees branch of Nix
(NixOS/nix#6530)
"warning: applying 'toString' to path '...' and then accessing it is deprecated, at '...'"
'else toString (/. + "${base}/${path}");' at line 183 may still cause a warning but i don't know how
to reach that codepath and test so im leaving it untouched
changing it to 'else /. + "${base}/${path}";'
caused this error
```
error: a string that refers to a store path cannot be appended to a path
at /home/systems/nixpkgs/lib/sources.nix:183:20:
182| then path
183| else /. + "${base}/${path}";
| ^
184| in if pathIsRegularFile path
```
It gives a warning on the lazy-trees branch of Nix
(NixOS/nix#6530)
one of these was also giving me an error (the one in lib/trivial probably)
```
$ nix build
warning: applying 'toString' to path '/home/artturin/nixgits/my-nixpkgs/nixos/modules/installer/sd-card/sd
-image-aarch64.nix' and then accessing it is deprecated, at /home/artturin/nixgits/my-nixpkgs/lib/modules.
nix:349:99
warning: applying 'toString' to path '/home/artturin/nixgits/my-nixpkgs/.git' and then accessing it is dep
recated, at /home/artturin/nixgits/my-nixpkgs/lib/sources.nix:35:32
warning: applying 'toString' to path '/home/artturin/nixgits/my-nixpkgs/nixos/modules/system/etc/etc.nix'
and then accessing it is deprecated, at «stdin»:0
warning: applying 'toString' to path '/home/artturin/nixgits/my-nixpkgs/nixos/modules/system/etc/etc-activ
ation.nix' and then accessing it is deprecated, at «stdin»:0
warning: applying 'toString' to path '/home/artturin/nixgits/my-nixpkgs/nixos/modules/installer/sd-card/sd
-image-aarch64.nix' and then accessing it is deprecated, at «stdin»:0
error: cannot decode virtual path '/nix/store/virtual0000000000000000000000005-source'
(use '--show-trace' to show detailed location information)
```
A tricky thing about FreeBSD is that there is no stable ABI across
versions. That means that putting in the version as part of the config
string is paramount.
We have a parsed represenation that separates name versus version to
accomplish this. We include FreeBSD versions 12 and 13 to demonstrate
how it works.
The code of `lib.closePropagation` was internally using a
recursion on the dependencies and returns all the derivation directly or
indirectly referenced by buildInputs.
`lib.closeProgation` is implemented in pure nix and uses an unique
function for list which is quadratic and does "true" equality, which
needs deep set comparison.
Instead, we use the `builtins.genericClosure` which is implemented as a
builtin and uses a more efficient sorting feature.
Note that `genericClosure` needs a `key` to discriminate the values, we
used the `outPath` which is unique and orderable.
On benchmarks, it performs up to 15x time faster on a benchmark related
to haskellPackages.ghcWithPackages.
Personally, I think that warnings such as
warning: The option `services.redis.enable' defined in `/home/ma27/Projects/nixpkgs/test.nix@node-vm' has been renamed to `services.redis.servers..enable'.
are fairly confusing because of the `..` and it's more correct to
actually quote that. With this change the warning now looks like this:
warning: The option `services.redis.enable' defined in `/home/ma27/Projects/nixpkgs/test.nix@node-vm' has been renamed to `services.redis.servers."".enable'.
While implementing that I realized that you'd have
a similar problem whenever you use attribute-names that aren't
identifiers, e.g.
services.nginx.virtualHosts."example.org".locations."/".invalid = 23;
now results in the following error:
error: The option `interactive.nodes.vm.services.nginx.virtualHosts."example.org".locations."/".invalid' does not exist. Definition values:
- In `/home/ma27/Projects/nixpkgs/test.nix@node-vm': 23
Of course there are some corner-cases where this won't work: when
generating the manual, you display submodules like this:
services.nginx.virtualHosts.<name>
Since `<name>` isn't a value, but an indicator for a submodule, it must
not be quoted. This also applies to the following identifiers:
* `*` for `listOf submodule`
* `<function body>` for `functionTo`
This might not be correct if you actually have a submodule with an
attribute name called `<name>`, but I think it's an improvement over the
current situation and for this you'd probably need to make even more
complex changes to the module system.
The motivation is to have a single identifier for that. Useful for the
next commit where I'll try to escape option-parts correctly (options can
be any kind of strings, but unless these are Nix identifiers, they must
be quoted).
Since `<function body>` (or `<name>`/`*`) are special identifiers in
error messages and the manual, we need a unique way to mark an option
part as function call because these are not to be quoted.
Move already implemented functionality to the upper level so
it could be used in a more generic way.
Signed-off-by: Ivan Nikolaenko <ivan.nikolaenko@unikie.com>
This brings two benefits:
1. The complete list of collisions is printed in the whenever any colliding
attribute is accessed.
2. The sets are intersected using a C++ primitive, which runs in O(n) time
(intersecting pre-sorted lists) with small constants rather than interpreted
Nix code.
Thanks to @toonn for prompting this improvement.
```
nix-repl> pkgsCross.arm-embedded.stdenv.hostPlatform.emulatorAvailable pkgsCross.arm-embedded.buildPackages
false
nix-repl> pkgsCross.aarch64-multiplatform.stdenv.hostPlatform.emulatorAvailable pkgsCross.aarch64-multiplatform.buildPackages
true
```
will be useful for stuff like handling https://github.com/NixOS/nixpkgs/issues/187109
deprecate literalDocBook by adding a warning (that will not fire yet) to
its uses and other docbook literal strings by adding optional warning
message to mergeJSON.
The comment in lib/systems/default.nix for uname.processor indicates that it
should match `uname -p`. I tried that command and found that it reports
`unknown` on all of these machines:
- `x86_64-linux`
- `aarch64-linux`
- `mips64el-linux`
- `powerpc64le-linux`
The command `uname -m` reports the expected value on all of the above.
I think the comment is wrong. So I fixed it.
This attr provides the location of each definition.
This is particularly useful for introspecting options of type
`attrsOf`. E.g., it allows finding the location of a systemd
service definition by parsing
`options.systemd.services.definitionsWithLocations`.
This is particularly useful for disabling modules defined in a flake.
Example:
disabledModules = [ "${flake}/modules/mymodule.nix" ];
Previously, absolute string paths were internally prepended with `modulesPath`,
which caused the module filtering to fail.
Recent commit 59356f11c1 ("perlPackages: Ensure all packages have a
license", 2022-08-22) added a license field to Perl packages where the
license was missing. The above mentioned packages got assigned
`unfreeRedistributable` license, which is not precise and makes all
packages depending on them unbuildable without `NIXPKGS_ALLOW_UNFREE`.
The packages actually have a license which SPDX calls
BSD-4-Clause-Shortened (https://spdx.org/licenses/BSD-4-Clause-Shortened.html).
In this commit, we add this license to the list of allowed licenses
and change the license field of the mentioned packages.
Closes #188103
In Nixpkgs, we assume that the "config" field is a canonicalized GNU
triple. I noticed that non-canonical values were being used here,
because the pkgsCross.mips64el-linux-gnu triples did not contain the
vendor field, but the pkgsCross.mips64el-linux-gnu.pkgsStatic did.
Here, I've run all the MIPS triples in lib.systems.examples through
config.sub to canonicalize them. I think this will avoid nasty
surprises in future.
Tested by building Nix and the bootstrap files for
pkgsCross.mips64el-linux-gnu.
More nixpkgs code such as `boot.initrd.systemd.emergencyAccess` defines
options that takes hashed passwords, so move the type definition from
modules/ into lib/.
The type definition itself stays unchanged.
`m` must always be an attrset at this point. It is basically always
evaluated. This will make it throw when any of the attrs is accessed,
rather than just `config`. We assume that this will improve the error
message in more scenarios.
This has been deprecated for a long time, and it's doubtful it had any
users to start with. And having an undisablable warning when
enumarating platforms is not good.
These servers apparently no longer exist, since September 2, 2021[1].
If somebody needs this for non-Scaleway machines, they should suggest
its reintroduction with a different name.
[1]: https://news.ycombinator.com/item?id=27192757
Very confusingly, the `isPowerPC` predicate in
`lib/systems/inspect.nix` does *not* match `powerpc64le`!
This is because `isPowerPC` is defined as
isPowerPC = { cpu = cpuTypes.powerpc; };
Where `cpuTypes.powerpc` is:
{ bits = 32; significantByte = bigEndian; family = "power"; };
This means that the `isPowerPC` predicate actually only matches the
subset of machines marketed under this name which happen to be 32-bit
and running in big-endian mode which is equivalent to:
with stdenv.hostPlatform; isPower && isBigEndian && is32bit
This seems like a sharp edge that people could easily cut themselves
on. In fact, that has already happened: in
`linux/kernel/common-config.nix` there is a test which will always
fail:
(stdenv.hostPlatform.isPowerPC && stdenv.hostPlatform.is64bit)
A more subtle case of the strict isPowerPC being used instead of the
moreg general isPower accidentally are the GHC expressions:
Update pkgs/development/compilers/ghc/8.10.7.nix
Update pkgs/development/compilers/ghc/8.8.4.nix
Update pkgs/development/compilers/ghc/9.2.2.nix
Update pkgs/development/compilers/ghc/9.0.2.nix
Update pkgs/development/compilers/ghc/head.nix
Since the remaining legitimate use sites of isPowerPC are so few, remove
the isPowerPC predicate completely. The alternative expression above is
noted in the release notes as an alternative.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
canExecute is like isCompatible, but also checks that the Kernels are
_equal_, i.e. that both platforms use the same syscall interface. This
is crucial in order to actually be able to execute binaries for the
other platform.
isCompatible is dropped, since it has changed semantically and there's
no use case left in nixpkgs.
Since we (exclusively) use isCompatible to gauge whether platform a can
execute binaries built for platform b, mode switching CPUs are not to be
considered compatible for our purposes: Switching the mode of a CPU
usually requires a reset. At the very least we can't execute a mix of
executables for the two modes which would usually be the case in nixpkgs
where we may want to execute buildInputs for the hostPlatform in
addition to nativeBuildInputs for the buildPlatform.
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.
Currently the only way to set the description for a submodule type is to
use `freeformType`. This is not ideal as it requires setting a
freeform type, and evaluates the submodule config unnecessarily.
Instead, add a `description` argument to `submoduleWith`.
This reverts commit PR #167947.
Flakes aren't standardised and the `lib` namespace shouldn't be
polluted with utilities that serve only experimental uses.
This patch causes the autodetection code in lib/systems/platforms.nix
to return {} if it cannot detect the platform and one of the
platform.nix-detection-provided attributes (linux-kernel, gcc, and
rustc) are accessed, rather than silently assuming the "pc" platform
as was previously done.
It is definitely safe to assume that code using these attributes is
prepared to deal with `gcc` and `rustc` not being defined, because
many of the working entries in this file don't define it.
Regarding `linux-kernel` the situation is less certain, but some code
(`lib/systems/default.nix` for example) is already designed to deal
with that attribute being missing. At worst it would result in an
"attribute not found" error.
While adding mips64el bootstrap support to nixpkgs, the silent
assumption that mips64el routers are actually Intel PCs caused
significant frustration. This commit removes that assumption in order
to save people who port nixpkgs to new platforms in the future from
this frustration.
For other platforms like Intel and ARM, we can do
e.g. lib.platforms.aarch64 to get only the 64-bit ARM platorms, but
until now there were no equivalents for RISC-V.
Prior to this commit, nixpkgs would assume that every little-endian
mips32 system was a "fuloong2f_n32".
Not only are there plenty of mips32 chips other than the fuloong, but
the fuloong is actually a mips64 chip! Note that the "n32" ABI is
(confusingly) an ABI for 64-bit mips chips (like the "x32" ABI for
amd64 chips -- both are ABIs which use 32-bit pointers on an
otherwise-64-bit system).
This error causes far-ranging problems. One of them was particularly
difficult to track down: it caused GCC to select 128-bit `long double`
types, which is invalid for the mips32 ABI. This isn't noticed until
you try to build musl-libc, which is careful to check for these things.
Prior to this commit,
nix-build . -A pkgsCross.mipsel-linux-gnu.pkgsStatic.hello
would fail. With this commit and #170736, it succeeds.
There is only one ABI for 32-bit MIPS chips. Before mips64, it didn't
really have a name.
The 64-bit MIPS ABI comes in two flavors, "n64" and "n32". It is
commonplace to refer to the old 32-bit ABI as "o32" (MIPS and SGI
documents do this).
However, when configuring gcc, one must use --with-abi=32, not
--with-abi=o32.
Let's keep GCC happy with this commit.
Probably being the most prominent document demonstrating the problem,
configuration.nix(5) describes various types in plural, e.g.
- ` Type: list of strings`
- ` Type: list of systemd options`
However, there are other cases where appending "s" to the inner type
effectively changes the type, e.g.
- ```
Type: list of string matching the pattern
[a-zA-Z0-9@%:_.\-]+[.](service|socket|device|mount|automount|swap|target|path|timer|scope|slice)s
```
This should've read "list of string[s]..." but instead changes the
regular expression.
Simply drop the best-effort plural in favour of correctness and
simplicity rather than adding more grammar related logic/trying to fix
this.
* lib/strings: optimise hasInfix function
* lib/strings: optimise hasInfix further using regex
* rstudio: call hasInfix with a string
* lib/strings: remove let from hasInfix
Co-authored-by: pennae <82953136+pennae@users.noreply.github.com>
Co-authored-by: pennae <82953136+pennae@users.noreply.github.com>
This commit creates flakes.nix, which is a library containing functions
which relate to interacting with flakes. It also moves related functions
from trivial.nix into it.
This is essentially a copy of the function of the same name, from
flake-compat. callLocklessFlake is useful when trying to utilise a
flake.nix without a lock file, often for when you want to create a
subflake from within a parent flake.
Co-authored-by: Tom Bereknyei <tomberek@gmail.com>
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Closes #168327
The issue reported there can be demonstrated with the following
expression:
→ nix-instantiate --eval -E "with import ./. {}; pkgs.lib.options.showDefs [ { file = \"foo\"; value = pkgs.rust.packages.stable.buildRustPackages; } ]"
error: attempt to call something which is not a function but a string
at /home/ma27/Projects/nixpkgs/lib/trivial.nix:442:35:
441| isFunction = f: builtins.isFunction f ||
442| (f ? __functor && isFunction (f.__functor f));
| ^
443|
Basically, if a `__functor` is in an attribute-set at depth-limit,
`__functor` will be set to `"<unevaluated>"`. This however breaks
`lib.isFunction` which checks for a `__functor` by invoking `__functor`
with `f` itself.
The same issue - "magic" attributes being shadowed by `withRecursion` -
also applies to others such as
`__pretty`/`__functionArgs`/`__toString`.
Since these attributes have a low-risk of causing a stack overflow
(because these are flat attr-sets or even functions), ignoring them in
`withRecursion` seems like a valid solution.
This allows other module system consumers to
disable these docs via option merging.
For instance arion uses asciidoc instead of
docbook so that would look awful.
This commit adds an `isPower64` predicate to the two existing
predicates for this architecture (`isPower` and `isPowerPC`).
Note that `isPowerPC` matches only 32-bit machines, whereas `isPower`
matches both 64-bit and 32-bit machines. Prior to this commit there
was no single `isXXX` predicate for `powerpc64le`.
Documents the _module.args option, motivated by many usages in Flakes,
especially with the deprecation of extraArgs
(78ada83361)
The documentation rendering for this option had to be handled a bit
specially, since it's not declared in nixos/modules like all the other
NixOS options.
Co-Authored-By: pennae <github@quasiparticle.net>
Co-Authored-By: Robert Hensing <robert@roberthensing.nl>
This uses the levenshtein distance to look through all possible
arguments to find ones that are close to what was requested:
error: Function in /home/infinisil/src/nixpkgs/pkgs/tools/text/ripgrep/default.nix
called without required argument "fetchFromGithub",
did you mean "fetchFromGitHub" or "fetchFromGitLab"?
With https://github.com/NixOS/nix/pull/3468 (in current nixUnstable) the error
message becomes even better, adding line location info
Adds some functions related to string similarity:
- lib.strings.commonPrefixLength
- lib.strings.commonSuffixLength
- lib.strings.levenshtein
- lib.strings.levenshteinAtMost
types.optionSet has been deprecated for almost 10 years now
(0e333688ce)! A removal
was already attempted in 2019
(27982b408e), but it was promptly
reinstantiated since some third-party uses were discovered
(f531ce75e4).
It's finally time to remove it for good :)
The current logic assumes that everything that isn't a derivation is a
store path, but it can also be something that's *coercible* to a store
path, like a flake input.
Unnecessary uses of `lib.toDerivation` result in errors in pure evaluation
mode when `builtins.storePath` is disabled.
Also document what a `package` is.
