This is appears to be a fairly common mistake for beginners who want
to build larger things from the system configurations, such as NixOps
networks, etc. Further explanation seems appropriate.
The supposedly public nature of these functions has been holding
back module system maintenance, while usages of these functions
are expected to be rare. If used anywhere, presumably they're
emulating module system behavior because some use case isn't supported
properly. We should try to support such a use case directly, if it
even exists.
Some options have their default value set in the `config` instead of
`default`, for example to push `mkDefault`s down an attribute set.
In those cases, it's useful to provide a `defaultText` for informational
purposes.
Previously, there was no way to unset an option when overriding a
kernel, apart from writing out the attrset yourself. Now it's
possible with lib.mkForce lib.kernel.unset. It's important to be able
to do this, because setting an option in the override may cause other
options to become unused, which would fail the config build unless
they were overridden too.
It makes sense to allow platform definitions to opt out of having libc
at all. One use case would be targetting some obscure new Linux
target that doesn't have a libc implementation yet, and another is
UEFI, which is basically libc-less Windows.
Not having libc is not commonly specified in (GNU) triples (even
Linux's build system will just target either -gnu or -musl depending
on the platform), so instead, we use a separate attribute for it.
With removePrefix introduced in a future commit this law can then be
used to derive
removePrefix p (append p s) == subpath.normalise s
=> (wrap with append)
append p (removePrefix p (append p s)) == append p (subpath.normalise s)
=> (append is not influenced by subpath normalisation)
append p (removePrefix p (append p s)) == append p s
=> (substitute q = append p s)
append p (removePrefix p q) == q
Not included in the docs because it's not that important, just shows
that the first statement is more general than the second one (because
this derivation doesn't work the other way)
ofborg relies on the behavior that existed prior to
1c00bf3948, where evaluation would
immediately abort due to a missing argument (whether it be an aliased
package when `allowAliases = false;` or a typo'd or otherwise
nonexistent package).
If `callPackageWith` `throw`s instead of `abort`s, the following
`nix-env` invocation does not fail fast but instead silently skips the
attribute (assuming there is a package that has an aliased package in
its `autoArgs`):
$ nix-env -qa --json --file . --arg config '{ allowAliases = false; }' &>/dev/null
$ echo $?
0
This does change the error output when there is a missing package (for
any of the reasons mentioned above), though. Before this change, the
errors looked like this:
$ nix-build -A hello --arg config '{ allowAliases = false; }'
error:
… while calling the 'throw' builtin
at /home/vin/workspace/vcs/nixpkgs/master/lib/customisation.nix:179:65:
178|
179| in if missingArgs == [] then makeOverridable f allArgs else throw error;
| ^
180|
error: Function called without required argument "bash_5" at /home/vin/workspace/vcs/nixpkgs/master/pkgs/applications/misc/hello/default.nix:8, did you mean "bash" or "bashdb"?
And the errors now look like this:
$ nix-build -A hello --arg config '{ allowAliases = false; }'
error:
… while calling the 'abort' builtin
at /home/vin/workspace/vcs/nixpkgs/master/lib/customisation.nix:179:65:
178|
179| in if missingArgs == [] then makeOverridable f allArgs else abort error;
| ^
180|
error: evaluation aborted with the following error message: 'Function called without required argument "bash_5" at /home/vin/workspace/vcs/nixpkgs/master/pkgs/applications/misc/hello/default.nix:8, did you mean "bash" or "bashdb"?'
TimescaleDB provides two types of licenses, Apache 2.0 and Timescale Community License (TSL), with different feature sets. While all the code is in the same repository, the build
system can build both versions depending on the build parameters set in.
Co-authored-by: Emily Lange <git@indeednotjames.com>
lib.{hasPrefix,hasInfix,hasSuffix} would otherwise return an
always-false result, which can be very unexpected:
nix-repl> lib.strings.hasPrefix ./lib ./lib/meta.nix
false
- Christmas is over!
- Upstream has changed the name of the target triplet used for the JS
backend from js-unknown-ghcjs to javascript-unknown-ghcjs, since Cabal
calls the architecture "javascript":
6636b67023
Since the triplet is made up anyways, i.e. autoconf does not support
it and Rust uses different triplets for its emscripten backends, we'll
just change it as well.
- Upstream fixed the problem with ar(1) being invoked incorrectly by stage0:
e987e345c8
nixdoc takes everything from Type: to Example: as the type, which
misrendered a large part of the docs. it also drops sorely needed spaces
where the type had line breaks, so all has to be on one line (or use
non-standard literal spaces, which is probably worse).
also clarify what the `?` for arguments mean while we're here.
This makes the following work
disabledModules = [ foo.nixosModules.bar ];
even if `bar` is not a path, but rather a module such as
{ key = "/path/to/foo#nixosModules.bar"; config = ...; }
By supporting this, the user will often be able to use the same syntax
for both importing and disabling a module. This is becoming more relevant
because flakes promote the use of attributes to reference modules. Not
all of these modules in flake attributes will be identifiable, but with
the help of a framework such as flake-parts, these attributes can be
guaranteed to be identifiable (by outPath + attribute path).
LLVM-exception only makes sense when used with the Apache 2.0 license,
so let's combine them, so it's not possible to forget one of them like
happened with llvm_15.
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.
