| Age | Commit message (Collapse) | Author |
|---|
|
Don’t try and assume that we know the output paths when we’ve just built
with `--dry-run`. Instead make `--dry-run` follow a different code path
that won’t assume the knowledge of the output paths at all.
Fix #6275
|
|
|
|
I had started the trend of doing `std::visit` by value (because a type
error once mislead me into thinking that was the only form that
existed). While the optomizer in principle should be able to deal with
extra coppying or extra indirection once the lambdas inlined, sticking
with by reference is the conventional default. I hope this might even
improve performance.
|
|
In dry run mode, new derivations can't be create, so running the command on anything that has not been evaluated before results in an error message of the form `don't know how to build these paths (may be caused by read-only store access)`.
For comparison, the classical `nix-build --dry-run` doesn't use read-only mode.
Closes #1795
(cherry picked from commit 54525682df707742e58311c32e9c9cb18de1e31f)
|
|
In particular, this now works:
$ nix path-info --eval-store auto --store https://cache.nixos.org nixpkgs#hello
Previously this would fail as it would try to upload the hello .drv to
cache.nixos.org. Now the .drv is instantiated in the local store, and
then we check for the existence of the outputs in cache.nixos.org.
|
|
Fix #4925
|
|
Just a renaming for now
|
|
|
|
This allows us to namespace its constructors under it.
|
|
|
|
|
|
|
|
|
|
|
|
Add --json option to nix build to allow machine readable output on
stdout with all built derivations
Fixes #1930
|
|
This matches the already-existing `local-fs-store.cc`.
|
|
This was useful for an experiment with building Nix as a single
compilation unit. It's not very useful otherwise but also doesn't
hurt...
|
|
|
|
|
|
- `queryDerivationOutputMapAssumeTotal` -> `queryPartialDerivationOutputMap`
- `queryDerivationOutputMapAssumeTotal` -> `queryDerivationOutputMap
|
|
|
|
|
|
|
|
Occasionally, `nix-build --check` is fairly helpful and I'd like to be
able to use this feature for flakes that need to be built with `nix
build` as well.
|
|
I think this better captures the intent of what's going on: we either
have an opaque store path, or a drv path with some outputs.
Having this structure will also help us support CA derivations: we'll
have to allow the outpath paths to be optional, so the structure we gain
now makes up for the structure we loose then.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This also adds a '--profile' option to 'nix build' (replacing 'nix-env
--set').
|
|
(cherry picked from commit a0de58f471c9087d8e6cc60a6078f9940a125b15)
|
|
|
|
This replaces 'nix-env --set'. For example:
$ nix build --profile /nix/var/nix/profiles/system \
~/Misc/eelco-configurations:nixosConfigurations.vyr.config.system.build.toplevel
updates the NixOS system profile from a flake.
This could have been a separate command (e.g. 'nix set-profile') but
1) '--profile' is pretty similar to '--out-link'; and 2) '--profile'
could be useful for other command (like 'nix dev-shell').
|
|
|
|
|
|
This makes e.g. "nix build" do something more or less reasonable
(namely, build the default package of the flake in the current
directory).
|
|
This ensures that the lock file is updated *before* evaluating it, and
that it gets updated for any nix command, not just 'nix build'.
Also, while computing the lock file, allow arbitrary registry lookups,
not just at top-level.
Also, improve some error messages slightly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also fixed Eelco's PR comments
|
