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
This makes the callPackage detection stronger by syntactically detecting
whether an attribute is using callPackage
See the added test case for why this is needed.
- `fromlinecolumn` is added to be almost the reverse of `line`.
This is needed in the future to get from `builtins.unsafeGetAttrPos`
locations to the index for rnix
- Previously the semantics for newline indices were not really defined,
now they are, and make more sense.
- Now there's a unit test for these functions
Original commit from https://github.com/NixOS/nixpkgs/pull/282226,
message:
Running CI locally is broken becauses the `-I` argument:
- Clobbers $NIX_PATH
- Is wrong for two reasons:
- Has too many `..` elements, relative to the script's location
- Isn't relative to the script's location (as with *.nix files),
since shell scripts and POSIX in general interpret paths
relative to the current working directory, not the canonical
path of argv[0]
- Is inconsistent, since this script has symlinks pointing at it
from different depths in the repository
There is no way to set this flag statically in a way that will work
everywhere. The caller needs to use $NIX_PATH, or the script needs
to take the `-I` value as an argument.
This commit deletes the static `-I` flag.
Since context now uses the luametatex engine, which is not distributed with
texlive, the probability of breaking it when updating increases. Let's add a
simple test just in case.
Co-authored-by: Vincenzo Mantova <1962985+xworld21@users.noreply.github.com>
Without the change the eval fails as:
$ nix build --no-link -f. tests.cross.sanity
error: attribute 'qutebrowser' missing
at pkgs/test/cross/default.nix:157:5:
156| # Two web browsers -- exercises almost the entire packageset
157| pkgs.pkgsCross.aarch64-multiplatform.qt5.qutebrowser
| ^
158| pkgs.pkgsCross.aarch64-multiplatform.firefox
Stops enforcing that packages whose evaluation gets fixed have to be
moved to `pkgs/by-name`.
This didn't really cause problems before, but I don't think it's great
behavior, and now that NonApplicable is a thing, we can easily make this
work, whereas before it would've been a larger change.
Introduces NonApplicable as a state of a ratchet, to be used when the
ratchet doesn't make sense to have.
This fixes an odd problem where before, changing an attribute to use
e.g. `callPackage` suddenly requires moving it to `pkgs/by-name`, when that
shouldn't have been required.
- Renames EmptyNonAutoCalled to ManualDefinition and add some docs to
better explain what it's for
- Don't conflate the Ratchet type with the Context type, keep them
apart, making the code a bit cleaner, but also allows adding
additional context for a Tight ratchet in the future
- Change the signature of to_nixpkgs_problem to align with the other
ratchet function signatures
Since https://github.com/NixOS/nixpkgs/pull/279892, there's a separate
check that makes sure all changed Nix files evaluate. To not trigger
that, we need to remove all invalid Nix expressions from the tests.
