The generated file sets its own directory as the source, including the
generated file itself, which causes rebuilds when that file is
reformatted. We can avoid this by overriding the source with a filtered
version and using that throughout the tests.
See https://github.com/NixOS/nixpkgs/pull/320572 for more context
The source included way more files than it really needed.
This commit limits it to exactly those it needs.
This also makes sure that no rebuild is necessary when any Nix
file changes, in particular useful when we reformat the Nix files.
The previously used pattern was introduced in #318614, but technically
leaked the default flags into the global scope. While this would
probably not make much of a practical difference, making concatTo
support default values is a much cleaner approach.
The test fails without 64eaa63181
("stdenv: concatStringsSep: quote ${sep}")
Co-authored-by: Ivan Trubach <mr.trubach@icloud.com>
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
Fix overriding of vendorHash and various attributes via the fixed point
attribute support of stdenv.mkDerivation.
Pass as derivation attributes
goModules, modRoot, vendorHash, deleteVendor, and proxyVendor.
Move goModules and vendorHash out of passthru.
Co-authored-by: Doron Behar <doron.behar@gmail.com>
Allow users to pass arguments to `buildDotnetModule` in the form:
```nix
buildDotnetModule (finalAttrs: {
# Args
})
```
Exposing the behaviour of the underlying `mkDerivation` and allowing
packages to be defined in a recursive way that works correctly even when
the package is overridden, e.g. using `overrideAttrs`.
Added some simple test cases that piggyback on the existing
`structured-attrs` test.
*compressDrv* compresses files in a given derivation.
*compressDrvWeb* compresses a derivation for a loosely-defined
pre-compressed "web server" usage.
This intends to replace the `passthru.data-compressed` derivations that
have accumulated in nixpkgs with something more reusable.
'command -v builtin' returns 'builtin', which doesn't suit us since
we're looking for program in the given PATH. This could give us shebangs
like this:
#!builtin
which is surprising.
Switch to 'type -P command' which always returns a path, even if command
is both a builtin and an executable (for example 'test'), or fail is
'command' is just a builtin.
these were not updated to understand
hardeningUnsupportedFlagsByTargetPlatform when it was added
causing more tests to fail for clang than otherwise would
This reverts commit 81c06bc609.
Reason for revert: This change breaks the
`tests.haskell.cabalSdist.assumptionLocalHasDirectReference` test which
relies on checking for the test source store path in the resulting
derivation files. 81c06bc609 did not
account for this in the change (though it should be possible).
This fixes an error in nixpkgs-review when it tries to pass this to
buildEnv:
error: The store path [...]project-references-test is a file and can't
be merged into an environment using pkgs.buildEnv! at [...]-builder.pl
line 122.
This change refactors internal hooks used by buildDotnetModule to
support derivations with structured attributes. Note that this changes
variable names that the internal hooks expect.
Key test case: nixpkgs#pkgsStatic.pkgsLLVM.ncurses
Prior to this patch, this fails with errors such as:
```
error: undefined symbol: __cxa_throw
```
I think this is a reasonable solution because in #292043, libcxxabi was
'merged into libcxx', however, the commit message suggests that only
dynamic linking was accounted for, because it says:
```
* linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient.
```
Whereas, I found that if I tried linking a "hello world" C++ program
with a static hostPlatform, it failed unless -lc++abi was passed.
Signed-off-by: Peter Waller <p@pwaller.net>
This fixes using inputDerivation on derivations that are fixed-output.
Previously:
```
nix-repl> drv = runCommand "huh" { outputHash = "sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU="; outputHashAlgo = "sha256"; outputHashType = "flat"; } "touch $out"
nix-repl> drv.inputDerivation
«derivation /nix/store/d8mjs6cmmvsr1fv7psm6imis5pmh9bcs-huh.drv»
nix-repl> :b drv.inputDerivation
error: fixed output derivation 'huh' is not allowed to refer to other store paths.
You may need to use the 'unsafeDiscardReferences' derivation attribute, see the manual for more details.
```
Fixes: https://github.com/NixOS/nixpkgs/issues/304209
Noticed the following warning:
```
direnv: `nix_direnv_watch_file` is deprecated - use `watch_file`
```
Which seems to come from here:
6455f38a8d/direnvrc (L207)
Seems this check is no longer needed
check-by-name: Remove check from .envrc
Co-authored-by: Silvan Mosberger <github@infinisil.com>
Now that the previous commit removed all the .display()'s that were
previously necessary for PathBuf's, but now aren't for RelativePathBuf,
we can also inline the format! arguments
An edge case was allowed when it shouldn't be: A package defined in
`pkgs/by-name` could be overridden in `all-packages.nix` if it was of
the form `callPackage (<expr>) { <non-empty> }`.
This is not right, it's required that the first argument be the path
matching the package to be overridden.
This adds a test to check that a commit like 0a3dab4af3 would fail CI
After doing some improvements to the `pkgs/by-name` check I discovered
that sbcl shouldn't have been allowed in `pkgs/by-name` after all as is.
Specifically, the requirement is that if `pkgs/by-name/sb/sbcl` exists,
the definition of the `sbcl` attribute must look like
sbcl = callPackage ../by-name/sb/sbcl/package.nix { ... };
However it currently is an alias like
sbcl = sbcl_2_4_1;
This wasn't detected before because `sbcl_2_4_1` was semantically
defined using `callPackage`:
sbcl_2_4_1 = wrapLisp {
pkg = callPackage ../development/compilers/sbcl { version = "2.4.1"; };
faslExt = "fasl";
flags = [ "--dynamic-space-size" "3000" ];
};
However this doesn't syntactically match what is required.
In https://github.com/NixOS/nixpkgs/pull/285089 I introduced syntactic
checks for exactly this, but they were only used for packages not
already in `pkgs/by-name`.
Only now that I'm doing the refactoring to also use this check for
`pkgs/by-name` packages this problem is noticed.
While introducing this new check is technically an increase in
strictness, and therefore would justify adding a new ratchet, I consider
this case to be rare enough that we don't need to do that.
This commit introduces a test to prevent such regressions in the
future
Moving sbcl back out of `pkgs/by-name` will be done when the pinned CI is updated
- Detect manual use of _internalCallByNamePackageFile for packages in
`pkgs/by-name` (can't be done for others though)
- Separate error message for when attribute locations can't be
determined for `pkgs/by-name` attributes
- Much better structure of the code in eval.rs, representing more
closely what is being checked
- Much more extensive comments
