| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
https://en.wikipedia.org/wiki/Loris
|
|
this makes the codename globally accessible in the repo. The release is
not only for NixOS anymore.
|
|
Expands on some of the function comments and add some of the
special syntaxes recognised by nixdoc.
|
|
|
|
Since the `assertOneOf` uses `lib.generators`, they are not really trivial
anymore and should go into their own library file.
|
|
|
|
|
|
Broken in 62dca7c9a; the tricky thing is that it depends on nix version.
Explanation: https://github.com/NixOS/nix/issues/629
|
|
The amount of implementation detail really should not be the first thing in a
prominent file called `trivial.nix`.
|
|
- add section headers
- unify comment syntax
- add examples
Tested with:
nix-instantiate --strict --eval ./lib/tests/misc.nix
|
|
|
|
* lib: bitAnd, bitOr, bitXor
* lib: test for bitAnd, bitOr, bitXor
* lib: bitsize-agnostic zipIntBits
* lib: bitNot
* lib: bitNot
|
|
|
|
|
|
As suggested in https://github.com/NixOS/nixpkgs/pull/39416#discussion_r183845745
the versioning attributes in `lib` should be consistent to
`nixos/version` which implicates the following changes:
* `lib.trivial.version` -> `lib.trivial.release`
* `lib.trivial.suffix` -> `lib.trivial.versionSuffix`
* `lib.nixpkgsVersion` -> `lib.version`
As `lib.nixpkgsVersion` is referenced several times in `NixOS/nixpkgs`,
`NixOS/nix` and probably several user's setups. As the rename will cause
a notable impact it's better to keep `lib.nixpkgsVersion` as alias with
a warning yielded by `builtins.trace`.
|
|
The logic regarding the generated `.version-suffix` file is already
defined in `lib/trivial.nix` and shouldn't be duplicated in
`nixos/version`.
|
|
|
|
Among other things, this will allow *2nix tools to output plain data
while still being composable with the traditional
callPackage/.override interfaces.
|
|
|
|
|
|
This does break the API of being able to import any lib file and get
its libs, however I'm not sure people did this.
I made this while exploring being able to swap out docFn with a stub
in #2305, to avoid functor performance problems. I don't know if that
is going to move forward (or if it is a problem or not,) but after
doing all this work figured I'd put it up anyway :)
Two notable advantages to this approach:
1. when a lib inherits another lib's functions, it doesn't
automatically get put in to the scope of lib
2. when a lib implements a new obscure functions, it doesn't
automatically get put in to the scope of lib
Using the test script (later in this commit) I got the following diff
on the API:
+ diff master fixed-lib
11764a11765,11766
> .types.defaultFunctor
> .types.defaultTypeMerge
11774a11777,11778
> .types.isOptionType
> .types.isType
11781a11786
> .types.mkOptionType
11788a11794
> .types.setType
11795a11802
> .types.types
This means that this commit _adds_ to the API, however I can't find a
way to fix these last remaining discrepancies. At least none are
_removed_.
Test script (run with nix-repl in the PATH):
#!/bin/sh
set -eux
repl() {
suff=${1:-}
echo "(import ./lib)$suff" \
| nix-repl 2>&1
}
attrs_to_check() {
repl "${1:-}" \
| tr ';' $'\n' \
| grep "\.\.\." \
| cut -d' ' -f2 \
| sed -e "s/^/${1:-}./" \
| sort
}
summ() {
repl "${1:-}" \
| tr ' ' $'\n' \
| sort \
| uniq
}
deep_summ() {
suff="${1:-}"
depth="${2:-4}"
depth=$((depth - 1))
summ "$suff"
for attr in $(attrs_to_check "$suff" | grep -v "types.types"); do
if [ $depth -eq 0 ]; then
summ "$attr" | sed -e "s/^/$attr./"
else
deep_summ "$attr" "$depth" | sed -e "s/^/$attr./"
fi
done
}
(
cd nixpkgs
#git add .
#git commit -m "Auto-commit, sorry" || true
git checkout fixed-lib
deep_summ > ../fixed-lib
git checkout master
deep_summ > ../master
)
if diff master fixed-lib; then
echo "SHALLOW MATCH!"
fi
(
cd nixpkgs
git checkout fixed-lib
repl .types
)
|
|
|
|
Trivia != prelude. This is a better organized and less likely to
scare off new contributors.
|
|
Lib doc improvements
|
|
Fix typo in trivial.nix
|
|
|
|
|
|
Introduce `mapNullable` into lib and use it in a few places
|
|
Also simply some configure flag logic my grep also alerted me too.
|
|
For details see:
https://github.com/NixOS/nixpkgs/commit/24444513fb5#commitcomment-21767916
|
|
|
|
|
|
|
|
|
|
Putting information in external JSON files is IMHO not an improvement
over the idiomatic style of Nix expressions. The use of JSON doesn't
add anything over Nix expressions (in fact it removes expressive
power). And scattering package info over lots of little files makes
packages less readable over having the info in one file.
|
|
Deprecation warnings should not be used in Nixpkgs because they spam
innocent "nix-env -qa" users with (in this case) dozens of messages
that they can't do anything about.
This also reverts commit 2ca883338389b7ab995924a0cab0211993bdf1da.
|
|
Make `overridePackages` extend rather than replace existing overrides
|
|
|
|
|
|
This makes it easy to specify kernel patches:
boot.kernelPatches = [ pkgs.kernelPatches.ubuntu_fan_4_4 ];
To make the `boot.kernelPatches` option possible, this also makes it
easy to extend and/or modify the kernel packages within a linuxPackages
set. For example:
pkgs.linuxPackages.extend (self: super: {
kernel = super.kernel.override {
kernelPatches = super.kernel.kernelPatches ++ [
pkgs.kernelPatches.ubuntu_fan_4_4
];
};
});
Closes #15095
|
|
|
|
See also https://github.com/NixOS/nix/issues/749.
|
|
... to be compatible with https://github.com/NixOS/nix/pull/933
while not breaking compatibility with current nix.
|
|
|
|
This is meant to be used by packages who often re-generate their inputs.
Producing valid JSON is easier than nix, and also garantees it's purity.
|
|
|
|
These functions used to live in pkgs/development/haskell-modules/default.nix,
but they are generic, really, and should be easily accessible to everyone.
|
|
|
|
|
