`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>
We don't want to ignore config that can mess up machines. In general
this should always fail evaluation, as you think you are changing
behaviour and don't, which can easily create run-time errors we can
catch early.
Previously mkRemovedOptionModule would only show the replacement
instructions when the removed option was *defined*. With this change, it
also does so when an option is *used*.
This is essential for options that are only intended to be used such as
`security.acme.directory`, whose replacement instructions would never
trigger without this change because almost everybody only uses the
option and isn't defining it.
This change is API-compatible and hash-compatible with the previous
version.
At first I considered to write a rename function too, but adding
it name to cleanSourceWith was a no-brainer for ease of use. It
turns out that a rename function isn't any more useful than
cleanSourceWith.
To avoid having to write the identity predicate when renaming,
the filter is now optional.
builtins.path is supported since Nix 2.0 which is required by nixpkgs
This allows `apply` functions to return a valid value if they completely
ignore their argument, which is the case for the option renaming
functions like `mkAliasOptionModule`. Therefore this solves issue #63693
`sourceByRegex src regexes` should include a source file if one of the
regular expressions `regexes` matches the path of that file relative
to `src`.
However to compute this relative path `sourceByRegex` uses:
```
relPath = lib.removePrefix (toString src + "/") (toString path);
```
Note that `toString path` evaluates to an absolute file somewhere
under `src` and not under `/nix/store`.
The problem is that this doesn't work if `src` is a `cleanSourceWith`
invocation as well because `toString src` will then evaluate to
`src.outPath` which will evaluate to `builtins.filterSource ...` which
evaluates to a path in `/nix/store` which is not a prefix of `path`.
The solution is to replace `src` with `origSrc` where
```
origSrc = if isFiltered then src.origSrc else src;
isFiltered = src ? _isLibCleanSourceWith;
```
Test this by executing the following from the nixpkgs repo:
```
(cat << 'EOI'
let
pkgs = import ./. {};
in pkgs.runCommand "test-sourceByRegex" {
test_sourceByRegex =
let
src1 = pkgs.lib.sourceByRegex ./. [ "^test-sourceByRegex.nix$" ];
src2 = pkgs.lib.sourceByRegex src1 [ "^test-sourceByRegex.nix$" ];
in src2 + "/test-sourceByRegex.nix";
} ''
cp $test_sourceByRegex $out
''
EOI
) > test-sourceByRegex.nix
nix-build test-sourceByRegex.nix
```
The main purpose is to bring attention to `flip map`, which improves
code readablity. It is useful when ad-hoc anonymous function
grows two or more lines in `map` application:
```
map (lcfg:
let port = lcfg.port;
portStr = if port != defaultPort then ":${toString port}" else "";
scheme = if cfg.enableSSL then "https" else "http";
in "${scheme}://cfg.hostName${portStr}"
) (getListen cfg);
```
Compare this to `foreach`-style:
```
foreach (getListen cfg) (lcfg:
let port = lcfg.port;
portStr = if port != defaultPort then ":${toString port}" else "";
scheme = if cfg.enableSSL then "https" else "http";
in "${scheme}://cfg.hostName${portStr}"
);
```
This is similar to Haskell's `for` (http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Traversable.html#v:for)
This reverts commit ce2f74df2c.
Doubles are treated as -darwin here, to provide some consistency.
There is some ambiguity between “x86_64-darwin” and “i686-darwin”
which could refer to binaries linked between iOS simulator or real
macOS binaries. useiOSPrebuilt can be used to determine which to use,
however.
