| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This makes the type of these functions more apparent from the name.
|
|
`toHex` converts the given positive integer to a string of the hexadecimal
representation of that integer. For example:
```
toHex 0 => "0"
toHex 16 => "10"
toHex 250 => "FA"
```
`toBase base i` converts the positive integer `i` to a list of it
digits in the given `base`. For example:
```
toBase 10 123 => [ 1 2 3 ]
toBase 2 6 => [ 1 1 0 ]
toBase 16 250 => [ 15 10 ]
```
|
|
lib/strings: Add `sanitizeDerivationName` function
|
|
|
|
|
|
This doesn't work in pure mode.
|
|
|
|
The semantic difference between `encode` and `to` is not apparent.
Users are likely to confuse both functions (which leads to unexpected
error messages about the wrong types). Like in `generators.nix`, all
functions should be prefixed by `to`.
Furthermore, converting to a string depends on the target context. In
this case, it’s a POSIX shell, so we should name it that (compare
`escapeShellArg` in `strings.nix`).
We can later add versions that escape for embedding in e.g. python
scripts or similar.
|
|
... as suggested by @roberth
|
|
... as suggested by @roberth
This also caught a bug in rendering lists, which this change also fixes
|
|
... based on feedback from @edolstra
|
|
... as suggested by @edolstra
|
|
This adds a new utility to intelligently convert Nix records to
command line options to reduce boilerplate for simple use cases and to
also reduce the likelihood of malformed command lines
|
|
`pipe` is a useful operator for creating pipelines of functions.
It works around the usual problem of e.g. string operations becoming
deeply nested functions.
In principle, there are four different ways this function could be
written:
pipe val [ f1 .. fn ]
pipe val [ fn .. f1 ]
compose [ f1 .. fn ] val
compose [ fn .. f1 ] val
The third and fourth form mirror composition of functions, they would
be the same as e.g. `(f1 << f2 << f3 .. << fn) val`.
However, it is not clear which direction the list should have (as one
can see in the second form, which is the most absurd.
In order not to confuse users, we decide for the most “intuitive”
form, which mirrors the way unix pipes work (thus the name `pipe`).
The flow of data goes from left to right.
Co-Authored-By: Silvan Mosberger <infinisil@icloud.com>
|
|
|
|
|
|
Since `isStorePath` relies on comparing against builtins.storeDir
(a string), we need to convert the input into a string as well.
|
|
|
|
|
|
|
|
|
|
|
|
* lib: bitAnd, bitOr, bitXor
* lib: test for bitAnd, bitOr, bitXor
* lib: bitsize-agnostic zipIntBits
* lib: bitNot
* lib: bitNot
|
|
|
|
|
|
toPath has confusing semantics and is never necessary; it can always
either just be omitted or replaced by pre-concatenating `/.`. It has
been marked as "!!! obsolete?" for more than 10 years in a C++
comment, hopefully removing it will let us properly deprecate and,
eventually, remove it.
|
|
|
|
So far, `mkValueString` defaulted to `toString`,
which is a bad match for most configuration file formats,
especially because how booleans are formatted.
This also improves error messages for unsupported types.
Add a test to codify the formatting.
|
|
|
|
This means the generation of values can now be influenced, even down from e.g.
an INI generator.
Breaks the interface of `mkKeyValueDefault` to match its interface to other
generator functions. It might me sensible to rename `mkKeyValue` and
`mkKeyValueSet` to conform to the `toX`-style of generator functions.
|
|
With `builtins.functionArgs` we can get some information if the first argument
is an attrset and whether the contained fields have default values. Encode that
into the pretty-printed lambda.
|
|
`toPretty` implements a pretty printer for nix values.
|
|
|
|
|
|
|
