lib.strings.escapeC produces single‐digit hexadecimal strings for
character values ≤ 15, which results in an ambiguity. If the following
character is a hex digit, it will be interpreted as being part of the
escape sequence.
systemd, which also relies on C‐style escape sequences, does not
decode single‐digit sequences at all, even if unambiguous.
Padding the hexadecimal string with "0" avoids this problem.
So we are adding a simplified version that builds a monolithic nix binary to get finished
in time for the release. Afterwards we will switch to the modular build again.
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
Previously if function in defs had set pattern in argument,
this information would be lost.
This keeps functionArgs in set pattern,
by using functor and `__functionArgs`
that is later used by `lib.functionArgs`.
This reverts commit ce8f304bb6.
The problem was simply a typo (nestedTypes.elemType ->
type.nestedTypes.elemType) ! And CI didn't run for lib in the orginal
PR which is why it didn't get caught.
This gives people some flexibility when they need a path type, and
prevents a "combinatorial explosion" of various path stops.
I've re-implemented our existing `path` and `pathInStore` types using
`pathWith`. Our existing `package` type is potentially a candidate for
similar treatment, but it's a little quirkier (there's some stuff with
`builtins.hasContext` and `toDerivation` that I don't completely
understand), and I didn't want to muddy this PR with that.
As a happy side effect of this work, we get a new feature: the ability
to create a type for paths *not* in the store. This is useful for when a
module needs a path to a file, and wants to protect people from
accidentally leaking that file into the nix store.
