We can now test returned paths being equal, no need to work around it
anymore by making sure paths aren't returned (which would import them
with the previous --json)
The Minimalist Gnu for Windows distribution comes with support for
the traditional msvcrt libc, as well as ucrt64 libc. The latter
being the newer universal compiler runtime. We follow the msys2
environment naming convention[1]:
| name | toolchain | arch | libc | libc++ |
|------------|-----------|---------|--------|-----------|
| mingw32 | gcc | i686 | msvcrt | libstdc++ |
| mingw64 | gcc | x86_64 | msvcrt | libstdc++ |
| ucrt64 | gcc | x86_64 | ucrt | libstdc++ |
| clang32 | llvm | i686 | ucrt | libc++ |
| clang64 | llvm | x86_64 | ucrt | libc++ |
| clangarm64 | llvm | aarch64 | ucrt | libc++ |
For now nixpkgs only supports the first three with this commit.
--
[1]: https://www.msys2.org/docs/environments/
Option added in 5b0ed68c106c1cbe3b573f3d1ca8c73eb203e346
it causes infinite recursion in cross builds
There's a another inf rec that needs 6946977de0de845e69a805f179b96a87d17640fa which is in staging
Added basic generators.toGitINI test.
Mostly taken from 958c06303f/tests/modules/programs/git/git.nix.
The ${"\t} escape is used so that the lines aren't recognized as "Wrong
indent style".
Right now converting `makeScope` to `makeScopeWithSplicing` is not
transparent to users and requires adding a warning for `overrideScope'`
in the set itself.
Warning and `overrideScope'` were added in 2018 b9dce11712d2bfc8cd367df5a7f737a5cec1e252 and there should be no users left after 5 years.
Deeply-curried functions are pretty error-prone in untyped languages
like Nix. This is a particularly bad case because
`top-level/splice.nix` *also* declares a makeScopeWithSplicing, but
it takes *two fewer arguments*.
Let's add a version that uses attrset-passing form, to provide some
minimal level of sanity-checking.
This also provides defaults for keep and extra (these are often
unneeded by the user).
These statements are taken from the `lib/test/release.nix` tests,
which previously also worked on darwin.
Unblocks https://github.com/NixOS/nix/pull/8569 when backported
This reverts commit c59c6b1c57da542b6b4af5d2ac27d1b99e7f0c5e.
This was a bit too ambitious, because no warnings were previously
triggered when `string` was nested e.g. `attrsOf string`, `nullOr
string`, etc.
Support for nested type deprecation warnings was introduced in
4b54aedee5e05aaf2838f6d951508b83e33d2baa, but had to be reverted in
a36e6760e9be0ec260b637a06d751d39e2a78e4e because it caused infinite
recursion for some users, and I couldn't remember that it was reverted.
The type has given a warning on use since [4 years ago](03392cd336b128a1639c648baf0f6c1a1271e0d2), I think it's safe to move the deprecation to the next stage: An error instead of a warning.
Before this commit, getExe assumes that if `meta.mainProgram` is unset,
it has a main program that's named after the package name.
While this is probable, it leads to a bad error when the assumption does
not hold. If the user called `getExe` themselves, they might narrow down
the location of the assumption quite easily, but if that's not the case,
they'll have to go down the rabbit hole to figure out what went wrong.
For example, a NixOS module may use `lib.getExe` on a package-typed option
which is then used in the system configuration. This then typically leads
to a failure *after* deployment, which is bad, and it's quite likely that
the user will debug the package output contents before digging through the
NixOS module, which is bad.
Furthermore the `getExe` call is rather inconspicuous as it does not
contain something like "/bin/foo", which is bad.
Also modules can be hard to read for a newbie, which is bad.
All of this can be avoided by requiring `meta.mainProgram`.
Many packages already have the attribute, and I would expect 80% of
`getExe` usages to be covered by 20% of packages, because plenty of
packages aren't used with `getExe` anyway.
Finally we could make an effort to set `mainProgram` semi-automatically
using `nix-index`.
Deeply-curried functions are pretty error-prone in untyped languages
like Nix. This is a particularly bad case because
`top-level/splice.nix` *also* declares a makeScopeWithSplicing, but
it takes *two fewer arguments*.
Let's switch to attrset-passing form, to provide some minimal level
of sanity-checking.
mkOption does not require a `type` argument and does not set the
resulting attribute if it is not given. Consequently, we need to be
prepared to merge options that have no type information.
