2017-03-30 22:03:40 +02:00
|
|
|
/*
|
|
|
|
|
Library of low-level helper functions for nix expressions.
|
2025-04-01 20:10:43 +02:00
|
|
|
|
2017-03-30 22:03:40 +02:00
|
|
|
Please implement (mostly) exhaustive unit tests
|
2023-01-02 07:51:54 +10:00
|
|
|
for new functions in `./tests.nix`.
|
2017-03-30 22:03:40 +02:00
|
|
|
*/
|
2016-09-15 01:21:42 +02:00
|
|
|
let
|
2006-09-25 10:07:59 +00:00
|
|
|
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
# A copy of `lib.makeExtensible'` in order to document `extend`.
|
|
|
|
|
# It has been leading to some trouble, so we have to document it specially.
|
|
|
|
|
makeExtensible' =
|
|
|
|
|
rattrs:
|
|
|
|
|
let
|
|
|
|
|
self = rattrs self // {
|
|
|
|
|
/**
|
|
|
|
|
Patch the Nixpkgs library
|
2025-04-01 20:10:43 +02:00
|
|
|
|
2025-01-29 22:05:21 +01:00
|
|
|
A function that applies patches onto the nixpkgs library.
|
|
|
|
|
Usage is discouraged for most scenarios.
|
2025-04-01 20:10:43 +02:00
|
|
|
|
2025-01-29 22:05:21 +01:00
|
|
|
:::{.note}
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
The name `extends` is a bit misleading, as it doesn't actually extend the library, but rather patches it.
|
|
|
|
|
It is merely a consequence of being implemented by `makeExtensible`.
|
2025-01-29 22:05:21 +01:00
|
|
|
:::
|
2025-04-01 20:10:43 +02:00
|
|
|
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
# Inputs
|
2025-04-01 20:10:43 +02:00
|
|
|
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
- An "extension function" `f` that returns attributes that will be updated in the returned Nixpkgs library.
|
2025-04-01 20:10:43 +02:00
|
|
|
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
# Output
|
2025-04-01 20:10:43 +02:00
|
|
|
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
A patched Nixpkgs library.
|
2025-04-01 20:10:43 +02:00
|
|
|
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
:::{.warning}
|
|
|
|
|
This functionality is intended as an escape hatch for when the provided version of the Nixpkgs library has a flaw.
|
2025-04-01 20:10:43 +02:00
|
|
|
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
If you were to use it to add new functionality, you will run into compatibility and interoperability issues.
|
2025-04-01 20:10:43 +02:00
|
|
|
:::
|
|
|
|
|
*/
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
extend = f: lib.makeExtensible (lib.extends f rattrs);
|
2025-04-01 20:10:43 +02:00
|
|
|
};
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
in
|
2025-04-01 20:10:43 +02:00
|
|
|
self;
|
|
|
|
|
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
lib = makeExtensible' (
|
2025-04-01 20:10:43 +02:00
|
|
|
self:
|
|
|
|
|
let
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
callLibs = file: import file { lib = self; };
|
|
|
|
|
in
|
2025-04-01 20:10:43 +02:00
|
|
|
{
|
|
|
|
|
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
# often used, or depending on very little
|
|
|
|
|
trivial = callLibs ./trivial.nix;
|
|
|
|
|
fixedPoints = callLibs ./fixed-points.nix;
|
2025-04-01 20:10:43 +02:00
|
|
|
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
# datatypes
|
|
|
|
|
attrsets = callLibs ./attrsets.nix;
|
|
|
|
|
lists = callLibs ./lists.nix;
|
|
|
|
|
strings = callLibs ./strings.nix;
|
|
|
|
|
stringsWithDeps = callLibs ./strings-with-deps.nix;
|
2025-04-01 20:10:43 +02:00
|
|
|
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
# packaging
|
|
|
|
|
customisation = callLibs ./customisation.nix;
|
2022-06-25 13:53:02 +02:00
|
|
|
derivations = callLibs ./derivations.nix;
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
maintainers = import ../maintainers/maintainer-list.nix;
|
|
|
|
|
teams = callLibs ../maintainers/team-list.nix;
|
|
|
|
|
meta = callLibs ./meta.nix;
|
|
|
|
|
versions = callLibs ./versions.nix;
|
2025-04-01 20:10:43 +02:00
|
|
|
|
lib: Discourage use of extend
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.
2025-01-23 08:27:29 +01:00
|
|
|
# module system
|
2018-04-06 18:51:10 +02:00
|
|
|
modules = callLibs ./modules.nix;
|
2017-07-28 20:05:35 -04:00
|
|
|
options = callLibs ./options.nix;
|
|
|
|
|
types = callLibs ./types.nix;
|
2025-04-01 20:10:43 +02:00
|
|
|
|
2017-07-28 20:05:35 -04:00
|
|
|
# constants
|
2018-04-06 18:51:10 +02:00
|
|
|
licenses = callLibs ./licenses.nix;
|
|
|
|
|
sourceTypes = callLibs ./source-types.nix;
|
2017-07-28 20:05:35 -04:00
|
|
|
systems = callLibs ./systems;
|
2025-04-01 20:10:43 +02:00
|
|
|
|
2017-07-28 20:05:35 -04:00
|
|
|
# serialization
|
2020-01-22 23:22:23 +01:00
|
|
|
cli = callLibs ./cli.nix;
|
2017-07-28 20:05:35 -04:00
|
|
|
gvariant = callLibs ./gvariant.nix;
|
|
|
|
|
generators = callLibs ./generators.nix;
|
2025-04-01 20:10:43 +02:00
|
|
|
|
|
|
|
|
# misc
|
2017-07-28 20:05:35 -04:00
|
|
|
asserts = callLibs ./asserts.nix;
|
|
|
|
|
debug = callLibs ./debug.nix;
|
|
|
|
|
misc = callLibs ./deprecated/misc.nix;
|
2025-04-01 20:10:43 +02:00
|
|
|
|
2017-07-28 20:05:35 -04:00
|
|
|
# domain-specific
|
|
|
|
|
fetchers = callLibs ./fetchers.nix;
|
2025-04-01 20:10:43 +02:00
|
|
|
|
2017-07-28 20:05:35 -04:00
|
|
|
# Eval-time filesystem handling
|
|
|
|
|
path = callLibs ./path;
|
|
|
|
|
filesystem = callLibs ./filesystem.nix;
|
|
|
|
|
fileset = callLibs ./fileset;
|
|
|
|
|
sources = callLibs ./sources.nix;
|
2025-04-01 20:10:43 +02:00
|
|
|
|
2017-07-28 20:05:35 -04:00
|
|
|
# back-compat aliases
|
|
|
|
|
platforms = self.systems.doubles;
|
2025-04-01 20:10:43 +02:00
|
|
|
|
2017-07-28 20:05:35 -04:00
|
|
|
# linux kernel configuration
|
|
|
|
|
kernel = callLibs ./kernel.nix;
|
2025-04-01 20:10:43 +02:00
|
|
|
|
2024-06-23 19:33:30 +03:00
|
|
|
# network
|
2017-07-28 20:05:35 -04:00
|
|
|
network = callLibs ./network;
|
2025-04-01 20:10:43 +02:00
|
|
|
|
2017-07-28 20:05:35 -04:00
|
|
|
# TODO: For consistency, all builtins should also be available from a sub-library;
|
|
|
|
|
# these are the only ones that are currently not
|
|
|
|
|
inherit (builtins)
|
2024-07-03 11:07:12 +02:00
|
|
|
addErrorContext
|
2017-07-28 20:05:35 -04:00
|
|
|
isPath
|
2025-04-01 20:10:43 +02:00
|
|
|
trace
|
|
|
|
|
typeOf
|
2022-06-25 13:53:02 +02:00
|
|
|
unsafeGetAttrPos
|
|
|
|
|
;
|
|
|
|
|
inherit (self.trivial)
|
2025-04-01 20:10:43 +02:00
|
|
|
id
|
2022-06-25 13:53:02 +02:00
|
|
|
const
|
2025-04-01 20:10:43 +02:00
|
|
|
pipe
|
2022-06-25 13:53:02 +02:00
|
|
|
concat
|
2025-04-01 20:10:43 +02:00
|
|
|
or
|
|
|
|
|
and
|
|
|
|
|
xor
|
2018-03-04 03:09:35 +00:00
|
|
|
bitAnd
|
2025-04-01 20:10:43 +02:00
|
|
|
bitOr
|
|
|
|
|
bitXor
|
2018-03-04 03:09:35 +00:00
|
|
|
bitNot
|
|
|
|
|
boolToString
|
|
|
|
|
mergeAttrs
|
|
|
|
|
flip
|
2025-04-01 20:10:43 +02:00
|
|
|
defaultTo
|
2018-03-04 03:09:35 +00:00
|
|
|
mapNullable
|
|
|
|
|
inNixShell
|
|
|
|
|
isFloat
|
|
|
|
|
min
|
|
|
|
|
max
|
|
|
|
|
importJSON
|
2022-03-27 16:48:33 +02:00
|
|
|
importTOML
|
2025-04-01 20:10:43 +02:00
|
|
|
warn
|
2019-10-27 22:44:24 +01:00
|
|
|
warnIf
|
2022-03-27 16:48:33 +02:00
|
|
|
warnIfNot
|
2019-10-27 22:44:24 +01:00
|
|
|
throwIf
|
2022-03-27 16:48:33 +02:00
|
|
|
throwIfNot
|
2019-10-27 22:44:24 +01:00
|
|
|
checkListOfEnum
|
|
|
|
|
info
|
|
|
|
|
showWarnings
|
2018-03-02 20:26:32 -08:00
|
|
|
nixpkgsVersion
|
|
|
|
|
version
|
2023-11-10 14:40:00 -03:00
|
|
|
isInOldestRelease
|
2024-10-08 11:02:09 +02:00
|
|
|
oldestSupportedReleaseIsAtLeast
|
2025-04-01 20:10:43 +02:00
|
|
|
mod
|
|
|
|
|
compare
|
2018-03-02 20:26:32 -08:00
|
|
|
splitByAndCompare
|
2025-04-01 20:10:43 +02:00
|
|
|
seq
|
|
|
|
|
deepSeq
|
|
|
|
|
lessThan
|
|
|
|
|
add
|
|
|
|
|
sub
|
2018-03-02 20:26:32 -08:00
|
|
|
functionArgs
|
2023-05-29 05:51:52 +08:00
|
|
|
setFunctionArgs
|
|
|
|
|
isFunction
|
|
|
|
|
toFunction
|
|
|
|
|
mirrorFunctionArgs
|
2023-11-10 14:40:00 -03:00
|
|
|
fromHexString
|
|
|
|
|
toHexString
|
|
|
|
|
toBaseDigits
|
2018-03-02 20:26:32 -08:00
|
|
|
inPureEvalMode
|
2025-04-01 20:10:43 +02:00
|
|
|
isBool
|
|
|
|
|
isInt
|
2023-11-10 14:40:00 -03:00
|
|
|
pathExists
|
2024-06-20 18:57:40 +02:00
|
|
|
genericClosure
|
2025-04-01 20:10:43 +02:00
|
|
|
readFile
|
2018-03-02 20:26:32 -08:00
|
|
|
;
|
2020-10-20 13:47:24 +02:00
|
|
|
inherit (self.fixedPoints)
|
2025-04-01 20:10:43 +02:00
|
|
|
fix
|
|
|
|
|
fix'
|
|
|
|
|
converge
|
|
|
|
|
extends
|
2018-03-02 20:26:32 -08:00
|
|
|
composeExtensions
|
2017-07-28 20:05:35 -04:00
|
|
|
composeManyExtensions
|
2024-07-04 20:37:01 +00:00
|
|
|
makeExtensible
|
2017-07-28 20:05:35 -04:00
|
|
|
makeExtensibleWithCustomName
|
|
|
|
|
toExtension
|
|
|
|
|
;
|
|
|
|
|
inherit (self.attrsets)
|
2022-02-20 19:23:12 +00:00
|
|
|
attrByPath
|
2020-10-20 13:47:24 +02:00
|
|
|
hasAttrByPath
|
2022-02-20 19:23:12 +00:00
|
|
|
setAttrByPath
|
2024-06-20 18:26:14 +02:00
|
|
|
getAttrFromPath
|
2025-04-01 20:10:43 +02:00
|
|
|
attrVals
|
2022-02-20 19:23:12 +00:00
|
|
|
attrNames
|
|
|
|
|
attrValues
|
2025-04-01 20:10:43 +02:00
|
|
|
getAttrs
|
2022-02-20 19:23:12 +00:00
|
|
|
catAttrs
|
2017-07-28 20:05:35 -04:00
|
|
|
filterAttrs
|
|
|
|
|
filterAttrsRecursive
|
2023-02-28 11:04:19 +01:00
|
|
|
foldlAttrs
|
|
|
|
|
foldAttrs
|
2017-07-28 20:05:35 -04:00
|
|
|
collect
|
|
|
|
|
nameValuePair
|
2025-04-01 20:10:43 +02:00
|
|
|
mapAttrs
|
|
|
|
|
mapAttrs'
|
2017-07-28 20:05:35 -04:00
|
|
|
mapAttrsToList
|
2023-09-10 17:56:29 +02:00
|
|
|
attrsToList
|
2017-07-28 20:05:35 -04:00
|
|
|
concatMapAttrs
|
2023-09-10 17:56:29 +02:00
|
|
|
mapAttrsRecursive
|
|
|
|
|
mapAttrsRecursiveCond
|
2025-04-01 20:10:43 +02:00
|
|
|
genAttrs
|
2023-09-10 17:56:29 +02:00
|
|
|
isDerivation
|
2020-01-22 23:22:23 +01:00
|
|
|
toDerivation
|
|
|
|
|
optionalAttrs
|
|
|
|
|
zipAttrsWithNames
|
2017-07-28 20:05:35 -04:00
|
|
|
zipAttrsWith
|
2024-04-21 16:03:31 +02:00
|
|
|
zipAttrs
|
|
|
|
|
recursiveUpdateUntil
|
2017-07-28 20:05:35 -04:00
|
|
|
recursiveUpdate
|
|
|
|
|
matchAttrs
|
|
|
|
|
mergeAttrsList
|
|
|
|
|
overrideExisting
|
2022-12-23 21:04:14 +01:00
|
|
|
showAttrPath
|
2023-08-17 00:55:32 +02:00
|
|
|
getOutput
|
|
|
|
|
getFirstOutput
|
2025-04-01 20:10:43 +02:00
|
|
|
getBin
|
2023-08-17 00:55:32 +02:00
|
|
|
getLib
|
2024-07-21 11:27:03 +00:00
|
|
|
getStatic
|
2025-04-01 20:10:43 +02:00
|
|
|
getDev
|
2024-07-21 11:27:03 +00:00
|
|
|
getInclude
|
2025-04-01 20:10:43 +02:00
|
|
|
getMan
|
2023-08-17 00:55:32 +02:00
|
|
|
chooseDevOutputs
|
2022-12-23 21:04:14 +01:00
|
|
|
zipWithNames
|
2025-04-01 20:10:43 +02:00
|
|
|
zip
|
2017-02-08 21:27:22 -05:00
|
|
|
recurseIntoAttrs
|
2020-10-20 13:47:24 +02:00
|
|
|
dontRecurseIntoAttrs
|
|
|
|
|
cartesianProduct
|
2024-06-20 19:01:19 +02:00
|
|
|
cartesianProductOfSets
|
|
|
|
|
mapCartesianProduct
|
|
|
|
|
updateManyAttrsByPath
|
|
|
|
|
listToAttrs
|
|
|
|
|
hasAttr
|
2024-07-03 11:07:12 +02:00
|
|
|
getAttr
|
|
|
|
|
isAttrs
|
|
|
|
|
intersectAttrs
|
2024-04-04 14:05:18 +00:00
|
|
|
removeAttrs
|
2025-04-01 20:10:43 +02:00
|
|
|
;
|
2024-04-04 14:05:18 +00:00
|
|
|
inherit (self.lists)
|
2024-11-20 22:51:15 +01:00
|
|
|
singleton
|
|
|
|
|
forEach
|
|
|
|
|
map
|
2025-04-01 20:10:43 +02:00
|
|
|
foldr
|
|
|
|
|
fold
|
2024-11-20 22:51:15 +01:00
|
|
|
foldl
|
2025-04-01 20:10:43 +02:00
|
|
|
foldl'
|
2024-11-20 22:51:15 +01:00
|
|
|
imap0
|
2025-04-01 20:10:43 +02:00
|
|
|
imap1
|
2024-11-20 22:51:15 +01:00
|
|
|
filter
|
|
|
|
|
ifilter0
|
|
|
|
|
concatMap
|
|
|
|
|
flatten
|
2024-10-08 11:02:09 +02:00
|
|
|
remove
|
|
|
|
|
findSingle
|
|
|
|
|
findFirst
|
2025-04-01 20:10:43 +02:00
|
|
|
any
|
|
|
|
|
all
|
|
|
|
|
count
|
|
|
|
|
optional
|
2024-10-08 11:02:09 +02:00
|
|
|
optionals
|
|
|
|
|
toList
|
2025-04-01 20:10:43 +02:00
|
|
|
range
|
2024-10-08 11:02:09 +02:00
|
|
|
replicate
|
|
|
|
|
partition
|
2022-12-17 21:57:17 +01:00
|
|
|
zipListsWith
|
2025-04-01 20:10:43 +02:00
|
|
|
zipLists
|
2024-10-08 11:02:09 +02:00
|
|
|
reverseList
|
2025-04-01 20:10:43 +02:00
|
|
|
listDfs
|
2024-10-08 11:02:09 +02:00
|
|
|
toposort
|
2025-04-01 20:10:43 +02:00
|
|
|
sort
|
2024-10-08 11:02:09 +02:00
|
|
|
sortOn
|
|
|
|
|
naturalSort
|
|
|
|
|
compareLists
|
2025-04-01 20:10:43 +02:00
|
|
|
take
|
2024-10-08 11:02:09 +02:00
|
|
|
drop
|
2025-04-01 20:10:43 +02:00
|
|
|
dropEnd
|
2024-10-08 11:02:09 +02:00
|
|
|
sublist
|
|
|
|
|
last
|
|
|
|
|
init
|
2025-01-03 12:03:48 +01:00
|
|
|
crossLists
|
2024-10-08 11:02:09 +02:00
|
|
|
unique
|
2025-01-03 12:03:48 +01:00
|
|
|
allUnique
|
2024-10-08 11:02:09 +02:00
|
|
|
intersectLists
|
2023-11-10 14:40:00 -03:00
|
|
|
subtractLists
|
2023-02-28 11:04:19 +01:00
|
|
|
mutuallyExclusive
|
2025-04-01 20:10:43 +02:00
|
|
|
groupBy
|
2023-09-10 17:56:29 +02:00
|
|
|
groupBy'
|
|
|
|
|
concatLists
|
2024-07-14 13:54:08 +00:00
|
|
|
genList
|
|
|
|
|
length
|
|
|
|
|
head
|
2025-04-01 20:10:43 +02:00
|
|
|
tail
|
|
|
|
|
elem
|
2024-07-14 13:54:08 +00:00
|
|
|
elemAt
|
2024-06-20 18:55:26 +02:00
|
|
|
isList
|
|
|
|
|
;
|
2024-06-20 16:07:35 +02:00
|
|
|
inherit (self.strings)
|
|
|
|
|
concatStrings
|
|
|
|
|
concatMapStrings
|
|
|
|
|
concatImapStrings
|
|
|
|
|
stringLength
|
2024-06-20 18:58:03 +02:00
|
|
|
substring
|
2024-06-20 16:07:35 +02:00
|
|
|
isString
|
2024-06-20 18:26:49 +02:00
|
|
|
replaceStrings
|
|
|
|
|
intersperse
|
|
|
|
|
concatStringsSep
|
2024-07-26 03:00:09 +08:00
|
|
|
concatMapStringsSep
|
2024-06-20 18:26:49 +02:00
|
|
|
concatMapAttrsStringSep
|
2022-12-17 21:57:17 +01:00
|
|
|
concatImapStringsSep
|
|
|
|
|
concatLines
|
2022-12-10 15:56:30 +01:00
|
|
|
makeSearchPath
|
2022-12-17 21:57:17 +01:00
|
|
|
makeSearchPathOutput
|
|
|
|
|
makeLibraryPath
|
2024-04-02 19:01:05 +02:00
|
|
|
makeIncludePath
|
|
|
|
|
makeBinPath
|
2022-12-17 21:57:17 +01:00
|
|
|
optionalString
|
2025-04-01 20:10:43 +02:00
|
|
|
hasInfix
|
2022-12-17 21:57:17 +01:00
|
|
|
hasPrefix
|
2019-02-04 00:09:38 -08:00
|
|
|
hasSuffix
|
2025-01-03 12:03:48 +01:00
|
|
|
stringToCharacters
|
|
|
|
|
stringAsChars
|
2025-04-01 20:10:43 +02:00
|
|
|
escape
|
2025-01-03 12:03:48 +01:00
|
|
|
escapeShellArg
|
2023-03-02 21:41:51 +01:00
|
|
|
escapeShellArgs
|
2025-01-03 12:03:48 +01:00
|
|
|
isStorePath
|
|
|
|
|
isStringLike
|
|
|
|
|
isValidPosixName
|
2025-04-01 20:10:43 +02:00
|
|
|
toShellVar
|
2025-01-03 12:03:48 +01:00
|
|
|
toShellVars
|
2020-10-20 13:47:24 +02:00
|
|
|
trim
|
2022-12-10 15:56:30 +01:00
|
|
|
trimWith
|
2019-02-04 00:09:38 -08:00
|
|
|
escapeRegex
|
2022-12-31 01:47:28 +01:00
|
|
|
escapeURL
|
|
|
|
|
escapeXML
|
|
|
|
|
replaceChars
|
|
|
|
|
lowerChars
|
2024-05-28 18:22:43 +01:00
|
|
|
upperChars
|
|
|
|
|
toLower
|
|
|
|
|
toUpper
|
|
|
|
|
toSentenceCase
|
|
|
|
|
addContextFrom
|
2025-02-13 15:28:35 +00:00
|
|
|
splitString
|
2019-11-24 16:19:32 +00:00
|
|
|
removePrefix
|
|
|
|
|
removeSuffix
|
|
|
|
|
versionOlder
|
|
|
|
|
versionAtLeast
|
2025-04-01 20:10:43 +02:00
|
|
|
getName
|
2024-06-20 17:58:37 +02:00
|
|
|
getVersion
|
|
|
|
|
match
|
|
|
|
|
split
|
2023-09-20 20:41:57 -03:00
|
|
|
cmakeOptionType
|
|
|
|
|
cmakeBool
|
|
|
|
|
cmakeFeature
|
2022-11-20 21:37:31 -03:00
|
|
|
mesonOption
|
|
|
|
|
mesonBool
|
|
|
|
|
mesonEnable
|
2018-05-11 11:12:15 -04:00
|
|
|
nameFromURL
|
|
|
|
|
enableFeature
|
|
|
|
|
enableFeatureAs
|
|
|
|
|
withFeature
|
2022-12-31 01:47:28 +01:00
|
|
|
withFeatureAs
|
|
|
|
|
fixedWidthString
|
|
|
|
|
fixedWidthNumber
|
2022-07-08 19:37:45 -04:00
|
|
|
toInt
|
|
|
|
|
toIntBase10
|
|
|
|
|
readPathsFromFile
|
|
|
|
|
fileContents
|
|
|
|
|
;
|
2020-10-20 13:47:24 +02:00
|
|
|
inherit (self.stringsWithDeps)
|
|
|
|
|
textClosureList
|
|
|
|
|
textClosureMap
|
2017-07-28 20:05:35 -04:00
|
|
|
noDepEntry
|
|
|
|
|
fullDepEntry
|
|
|
|
|
packEntry
|
|
|
|
|
stringAfter
|
|
|
|
|
;
|
2020-10-20 13:47:24 +02:00
|
|
|
inherit (self.customisation)
|
|
|
|
|
overrideDerivation
|
|
|
|
|
makeOverridable
|
2018-05-11 11:12:15 -04:00
|
|
|
callPackageWith
|
|
|
|
|
callPackagesWith
|
|
|
|
|
extendDerivation
|
|
|
|
|
hydraJob
|
2023-05-28 11:26:14 +00:00
|
|
|
makeScope
|
|
|
|
|
makeScopeWithSplicing
|
|
|
|
|
makeScopeWithSplicing'
|
|
|
|
|
extendMkDerivation
|
|
|
|
|
;
|
2024-11-11 19:59:34 +00:00
|
|
|
inherit (self.derivations) lazyDerivation optionalDrvAttr warnOnInstantiate;
|
2025-03-15 10:26:57 +00:00
|
|
|
inherit (self.generators) mkLuaInline;
|
2020-10-20 13:47:24 +02:00
|
|
|
inherit (self.meta)
|
|
|
|
|
addMetaAttrs
|
|
|
|
|
dontDistribute
|
|
|
|
|
setName
|
|
|
|
|
updateName
|
2018-11-18 08:26:13 +00:00
|
|
|
appendToName
|
|
|
|
|
mapDerivationAttrset
|
|
|
|
|
setPrio
|
|
|
|
|
lowPrio
|
|
|
|
|
lowPrioSet
|
|
|
|
|
hiPrio
|
2024-08-25 00:57:44 +02:00
|
|
|
hiPrioSet
|
|
|
|
|
licensesSpdx
|
|
|
|
|
getLicenseFromSpdxId
|
|
|
|
|
getLicenseFromSpdxIdOr
|
|
|
|
|
getExe
|
|
|
|
|
getExe'
|
|
|
|
|
;
|
2023-11-27 17:14:36 -08:00
|
|
|
inherit (self.filesystem)
|
|
|
|
|
pathType
|
|
|
|
|
pathIsDirectory
|
|
|
|
|
pathIsRegularFile
|
|
|
|
|
packagesFromDirectoryRecursive
|
|
|
|
|
;
|
2023-04-05 16:10:09 +02:00
|
|
|
inherit (self.sources)
|
|
|
|
|
cleanSourceFilter
|
2017-07-28 20:05:35 -04:00
|
|
|
cleanSource
|
|
|
|
|
sourceByRegex
|
|
|
|
|
sourceFilesBySuffices
|
2018-05-11 11:12:15 -04:00
|
|
|
commitIdFromGitRepo
|
|
|
|
|
cleanSourceWith
|
|
|
|
|
pathHasContext
|
2023-04-05 16:10:09 +02:00
|
|
|
canCleanSource
|
|
|
|
|
pathIsGitRepo
|
|
|
|
|
;
|
2021-12-17 15:17:49 +01:00
|
|
|
inherit (self.modules)
|
|
|
|
|
evalModules
|
|
|
|
|
setDefaultModuleLocation
|
2022-03-21 22:54:07 +01:00
|
|
|
unifyModuleSyntax
|
|
|
|
|
applyModuleArgsIfFunction
|
|
|
|
|
mergeModules
|
2024-01-29 08:58:33 +01:00
|
|
|
mergeModules'
|
|
|
|
|
mergeOptionDecls
|
|
|
|
|
mergeDefinitions
|
2017-07-28 20:05:35 -04:00
|
|
|
pushDownProperties
|
|
|
|
|
dischargeProperties
|
|
|
|
|
filterOverrides
|
|
|
|
|
sortProperties
|
|
|
|
|
fixupOptionType
|
|
|
|
|
mkIf
|
|
|
|
|
mkAssert
|
2025-03-17 16:17:54 +00:00
|
|
|
mkDefinition
|
2017-07-28 20:05:35 -04:00
|
|
|
mkMerge
|
|
|
|
|
mkOverride
|
2021-08-18 14:20:41 +02:00
|
|
|
mkOptionDefault
|
|
|
|
|
mkDefault
|
|
|
|
|
mkImageMediaOverride
|
|
|
|
|
mkForce
|
|
|
|
|
mkVMOverride
|
2021-07-12 07:23:45 +02:00
|
|
|
mkFixStrictness
|
|
|
|
|
mkOrder
|
|
|
|
|
mkBefore
|
|
|
|
|
mkAfter
|
|
|
|
|
mkAliasDefinitions
|
2017-07-28 20:05:35 -04:00
|
|
|
mkAliasAndWrapDefinitions
|
|
|
|
|
fixMergeModules
|
|
|
|
|
mkRemovedOptionModule
|
2022-03-09 14:41:43 +01:00
|
|
|
mkRenamedOptionModule
|
|
|
|
|
mkRenamedOptionModuleWith
|
|
|
|
|
mkMergedOptionModule
|
|
|
|
|
mkChangedOptionModule
|
2022-12-30 20:43:53 +01:00
|
|
|
mkAliasOptionModule
|
|
|
|
|
mkDerivedConfig
|
|
|
|
|
doRename
|
|
|
|
|
mkAliasOptionModuleMD
|
|
|
|
|
;
|
2024-01-29 08:58:33 +01:00
|
|
|
evalOptionValue = lib.warn "External use of `lib.evalOptionValue` is deprecated. If your use case isn't covered by non-deprecated functions, we'd like to know more and perhaps support your use case well, instead of providing access to these low level functions. In this case please open an issue in https://github.com/nixos/nixpkgs/issues/." self.modules.evalOptionValue;
|
2020-10-20 13:47:24 +02:00
|
|
|
inherit (self.options)
|
|
|
|
|
isOption
|
|
|
|
|
mkEnableOption
|
|
|
|
|
mkSinkUndeclaredOptions
|
2022-01-24 01:07:32 +01:00
|
|
|
mergeDefaultOption
|
|
|
|
|
mergeOneOption
|
|
|
|
|
mergeEqualOption
|
|
|
|
|
mergeUniqueOption
|
|
|
|
|
getValues
|
|
|
|
|
getFiles
|
|
|
|
|
optionAttrSetToDocList
|
|
|
|
|
optionAttrSetToDocList'
|
2023-06-11 19:51:46 +02:00
|
|
|
scrubOptionValue
|
|
|
|
|
literalExpression
|
|
|
|
|
literalExample
|
2022-06-15 13:11:22 +02:00
|
|
|
showOption
|
|
|
|
|
showOptionWithDefLocs
|
|
|
|
|
showFiles
|
2022-12-30 21:04:52 +01:00
|
|
|
unknownModule
|
|
|
|
|
mkOption
|
|
|
|
|
mkPackageOption
|
|
|
|
|
mkPackageOptionMD
|
2024-11-17 11:05:34 +01:00
|
|
|
literalMD
|
|
|
|
|
;
|
2020-10-20 13:47:24 +02:00
|
|
|
inherit (self.types)
|
|
|
|
|
isType
|
|
|
|
|
setType
|
|
|
|
|
defaultTypeMerge
|
|
|
|
|
defaultFunctor
|
2017-07-28 20:05:35 -04:00
|
|
|
isOptionType
|
|
|
|
|
mkOptionType
|
|
|
|
|
;
|
2020-10-20 13:47:24 +02:00
|
|
|
inherit (self.asserts)
|
2018-08-08 19:26:52 +02:00
|
|
|
assertMsg
|
|
|
|
|
assertOneOf
|
|
|
|
|
;
|
2023-02-24 16:28:06 +01:00
|
|
|
inherit (self.debug)
|
|
|
|
|
traceIf
|
|
|
|
|
traceVal
|
|
|
|
|
traceValFn
|
|
|
|
|
traceSeq
|
|
|
|
|
traceSeqN
|
|
|
|
|
traceValSeq
|
|
|
|
|
traceValSeqFn
|
|
|
|
|
traceValSeqN
|
|
|
|
|
traceValSeqNFn
|
|
|
|
|
traceFnSeqN
|
|
|
|
|
runTests
|
|
|
|
|
testAllTrue
|
|
|
|
|
;
|
2020-10-20 13:47:24 +02:00
|
|
|
inherit (self.misc)
|
|
|
|
|
maybeEnv
|
|
|
|
|
defaultMergeArg
|
|
|
|
|
defaultMerge
|
|
|
|
|
foldArgs
|
2017-07-28 20:05:35 -04:00
|
|
|
maybeAttrNullable
|
|
|
|
|
maybeAttr
|
|
|
|
|
ifEnable
|
|
|
|
|
checkFlag
|
|
|
|
|
getValue
|
|
|
|
|
checkReqs
|
|
|
|
|
uniqList
|
|
|
|
|
uniqListExt
|
|
|
|
|
condConcat
|
|
|
|
|
lazyGenericClosure
|
|
|
|
|
innerModifySumArgs
|
|
|
|
|
modifySumArgs
|
|
|
|
|
innerClosePropagation
|
|
|
|
|
closePropagation
|
|
|
|
|
mapAttrsFlatten
|
|
|
|
|
nvs
|
|
|
|
|
setAttr
|
|
|
|
|
setAttrMerge
|
|
|
|
|
mergeAttrsWithFunc
|
|
|
|
|
mergeAttrsConcatenateValues
|
|
|
|
|
mergeAttrsNoOverride
|
|
|
|
|
mergeAttrByFunc
|
|
|
|
|
mergeAttrsByFuncDefaults
|
2018-07-26 12:05:40 +02:00
|
|
|
mergeAttrsByFuncDefaultsClean
|
|
|
|
|
mergeAttrBy
|
2020-05-11 23:04:41 +01:00
|
|
|
fakeHash
|
|
|
|
|
fakeSha256
|
|
|
|
|
fakeSha512
|
2018-07-26 12:05:40 +02:00
|
|
|
nixType
|
|
|
|
|
imap
|
|
|
|
|
;
|
2020-10-20 13:47:24 +02:00
|
|
|
inherit (self.versions)
|
2019-09-24 10:47:34 +02:00
|
|
|
splitVersion
|
|
|
|
|
;
|
2018-04-06 18:51:10 +02:00
|
|
|
}
|
|
|
|
|
);
|
2017-07-28 20:05:35 -04:00
|
|
|
in
|
|
|
|
|
lib
|