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.
Since https://github.com/NixOS/nixpkgs/pull/281374, the
nixpkgs-check-by-name tooling is pinned to a specific /nix/store path to
avoid having to evaluate Nixpkgs in CI.
The same path is used for local runs, but that doesn't actually work
when you're trying to run it on a platform different from CI.
This commit makes it work by being clearer about platforms and making
local runs check out the correct Nixpkgs to evaluate the tool from.
Before this, the tool for CI would update when nixos-unstable updated,
which is kind of terrible because you don't know when it happens, and it
might break master.
In fact, the tooling _right now_ has a serious bug and shouldn't be used!
This PR addresses this by _pinning_ the tooling in Nixpkgs itself.
Updating the tooling now requires two PRs:
- The first PR to update the tooling source
- (wait for Hydra to build and publish it in nixos-unstable)
- The second PR to update the pinned tooling
In turn you know exactly when the changes are going to take effect.
This change however has additional benefits:
- It makes CI more reproducible, because it doesn't depend on the state
of nixos-unstable anymore
- Updates to the tooling can be tested with the workflow itself,
because PRs that update the pinned tool will be tested on the updated
version
- CI gets a sizable speed boost, because there's no need to download and
evaluate a channel anymore
- It makes it more realistic to move the source of the tool into a
separate repository
- It removes the brittle branch-specific logic that was previously
needed to ensure that release branches use their own version of the
tooling.
nix-build failed because the tests assume to run in a CWD equal to the
project root, which is not the case in the derivation build.
This commit fixes it by not using hacky `..` references to paths,
and instead uses NIX_PATH for all implicit Nix testing path
dependencies.
Also the root of the `lib` path gets passed in from the `default.nix`
file, so all the relative path handling is done by Nix during evaluation
already, and in the Nix store when possible.
The current version of linear (1.22) has incorrect constraints in its
cabal file (which has been corrected in a revision), so it is causing
this test to fail.
This commit just switches to another arbitrary package (cereal) for the
tests.
- Typo
- Rename AttributeRatchet to ToNixpkgsProblem
- Make the compare trait method into a RatchetState method
Co-Authored-By: Philip Taron <philip.taron@gmail.com>
All other functions are in the form of `*{c,C}heckpointBuild*`, so we
deprecate the `mkCheckpointedBuild` function in favor of `mkCheckpointBuild`.
Also address some inconsistencies in the docs: some `buildOutput` should
actually be `incrementalBuildArtifacts`.
This makes the attribute ratchet check logic more re-usable, which will
be used in a future commit.
It also renames the ratchet states to something more intuitive
This commit adds a test for the newly added support for
__structuredAttrs in autoPatchelf(hook). It copied a reasonably
small-closure binary derivation that makes use of autoPatchelf, stripped
it down for the purpose of the test, and check that autoPatchelf
correctly set the interpreter and runpath whether __structuredAttrs is
set to true or not.
Due to the check soon depending on the base branch (see `--base`),
the CI check can't reasonably share all code with a local check.
We can still make a script to run it locally, just not sharing all code.
This derivation verifies that all jobset attributes can be evaluated
under tryEval without producing any non-catchable errors or causing
infinite recursion.
Previously, not passing `--base` would enforce the most strict checks.
While there's currently no actual violation of these stricter checks,
this does not match the previous behavior.
This won't matter once CI passes `--base`, the code handling the
optionality can be removed then.
This implements the option for a gradual migration to stricter checks.
For now this is only done for the check against empty non-auto-called
callPackage arguments, but in the future this can be used to ensure all
new packages make use of `pkgs/by-name`.
This is implemented by adding a `--base <BASE_NIXPKGS>` flag, which then
compares the base nixpkgs against the main nixpkgs version, making sure
that there are no regressions.
The `--version` flag is removed. While it was implemented, it was never
used in CI, so this is fine.
This prepares the code base for the removal of the `--version` flag, to
be replaced with a flag that can specify a base version to compare the
main Nixpkgs against, in order to have gradual transitions to stricter
checks.
This refactoring does:
- Introduce the `version` module that can house the logic to increase
strictness, with a `version::Nixpkgs` struct that contains the
strictness conformity of a single Nixpkgs version
- Make the check return `version::Nixpkgs`
- Handle the behavior of the still-existing `--version` flag with `version::Nixpkgs`
- Introduce an intermediate `process` function to handle the top-level
logic, especially useful in the next commit
Convenience function to run another validation over a successful validation result.
This will be usable in more locations in future commits, making the code
nicer.
This makes it such that these two errors can both be thrown for a single
package:
- The attribute value not being a derivation
- The attribute not being a proper callPackage
The tests had to be adjusted to only throw the error they were testing
for
cudaPackages.cuda_compat: ignore missing libs provided at runtime
cudaPackages.gpus: Jetson should never build by default
cudaPackages.flags: don't build Jetson capabilities by default
cudaPackages: re-introduce filter for pre-existing CUDA redist packages in overrides
cudaPackages: only recurseIntoAttrs for the latest of each major version
cudaPackages.nvccCompatabilities: use GCC 10 through CUDA 11.5 to avoid a GLIBC incompatability
cudaPackages.cutensor: acquire libcublas through cudatoolkit prior to 11.4
cudaPackages.cuda_compat: mark as broken on aarch64-linux if not targeting Jetson
cudaPackages.cutensor_1_4: fix build
cudaPackages: adjust use of autoPatchelfIgnoreMissingDeps
cudaPackages.cuda_nvprof: remove unecessary override to add addOpenGLRunpath
cudaPackages: use getExe' to avoid patchelf warning about missing meta.mainProgram
cudaPackages: fix evaluation with Nix 2.3
cudaPackages: fix platform detection for Jetson/non-Jetson aarch64-linux
python3Packages.tensorrt: mark as broken if required packages are missing
Note: evaluating the name of the derivation will fail if tensorrt is not present,
which is why we wrap the value in `lib.optionalString`.
cudaPackages.flags.getNixSystem: add guard based on jetsonTargets
cudaPackages.cudnn: use explicit path to patchelf
cudaPackages.tensorrt: use explicit path to patchelf
