| Age | Commit message (Collapse) | Author |
|---|
|
`nix flake show` now skips derivations for foreign systems: https://github.com/NixOS/nix/pull/6988
This commit borrows from that to implement the same behavior for `nix flake check`.
See "nix flake check breaks on IFD in multi-platform flake" https://github.com/NixOS/nix/issues/4265
|
|
|
|
Fix ControlMaster behaviour
|
|
|
|
Fix the segfault on `nix profile install` with conflict
|
|
undefined
|
|
- If the element comes from a flake, print the full flakeref (with the
fragment part) and not just the reference to the flake itself
- If the element doesn't come from a flake, print its store path(s)
This is a bit too verbose, but has the advantages of being correct (and
not crashing), so it's strictly better than the previous situation
Fix https://github.com/NixOS/nix/issues/8284
|
|
As discussed in #7417, it would be good to make more string values work
as installables. That is to say, if an installable refers to a value,
and the value is a string, it used to not work at all, since #7484, it
works somewhat, and this PR make it work some more.
The new cases that are added for `BuiltPath` contexts:
- Fixed input- or content-addressed derivation:
```
nix-repl> hello.out.outPath
"/nix/store/jppfl2bp1zhx8sgs2mgifmsx6dv16mv2-hello-2.12"
nix-repl> :p builtins.getContext hello.out.outPath
{ "/nix/store/c7jrxqjhdda93lhbkanqfs07x2bzazbm-hello-2.12.drv" = { outputs = [ "out" ]; }; }
The string matches the specified single output of that derivation, so
it should also be valid.
- Floating content-addressed derivation:
```
nix-repl> (hello.overrideAttrs (_: { __contentAddressed = true; })).out.outPath
"/1a08j26xqc0zm8agps8anxpjji410yvsx4pcgyn4bfan1ddkx2g0"
nix-repl> :p builtins.getContext (hello.overrideAttrs (_: { __contentAddressed = true; })).out.outPath
{ "/nix/store/qc645pyf9wl37c6qvqzaqkwsm1gp48al-hello-2.12.drv" = { outputs = [ "out" ]; }; }
```
The string is not a path but a placeholder, however it also matches
the context, and because it is a CA derivation we have no better
option. This should also be valid.
We may also want to think about richer attrset based values (also
discussed in that issue and #6507), but this change "completes" our
string-based building blocks, from which the others can be desugared
into or at least described/document/taught in terms of.
Progress towards #7417
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
Regression test for https://github.com/NixOS/nix/issues/8294
|
|
Fixes #8309
This regression was because both `CmdDevelop` and `CmdPrintDevEnv` were
switched to be `InstallableValueCommand` subclasses, but actually
neither should have been.
The `nixpkgsFlakeRef` method should indeed not be on the base
installable class, because "flake refs" and "nixpkgs" are not
installable-wide notions, but that doesn't mean these commands should
only accept installable values.
|
|
Derivations can output "text-hashed" data
|
|
Also pass unwanted outputs to post-build-hook
|
|
|
|
|
|
This fixes a bug in commands like `nix eval' which would emit invalid attribute
sets if they contained reserved keywords such as "assert", "let", etc.
These keywords will not be quoted when printed, making them valid expressions.
All keywords recognized by the lexer are quoted except "or", which does not
require quotation.
|
|
Trustless remote building for input-addressed drvs
|
|
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
|
|
|
|
fe5509df caused only wanted outputs to be passed to the
post-build-hook, which resulted in paths being built
without ever going into the hook.
This commit adds a (currently failing) test for this.
|
|
|
|
|
|
In this one, we don't just output an existing derivation as is, but
modify it first.
|
|
I found it hard to read as a big string literal.
|
|
|
|
|
|
|
|
I suppose we can use `dynamic-derivations` for the few things we neeed.
|
|
|
|
This is an entry point for outside data, so we need to check enabled
experimental features here.
|
|
trustless-remote-builder-simple
|
|
Experimentally allow forcing `nix-daemon` trust; use this to test
|
|
We finally test the status quo of remote build trust in a number of
ways. We create a new experimental feature on `nix-daemon` to do so.
PR #3921, which improves the situation with trustless remote building,
will build upon these changes. This code / tests was pull out of there
to make this, so everything is easier to review, and in particular we
test before and after so the new behavior in that PR is readily apparent
from the testsuite diff alone.
|
|
Issues:
1. Features gated on disabled experimental settings should warn and be
ignored, not silently succeed.
2. Experimental settings in the same config "batch" (file or env var)
as the enabling of the experimental feature should work.
3. For (2), the order should not matter.
These are analogous to the issues @roberth caught with my changes for
arg handling, but they are instead for config handling.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
|
|
And only enable in the tests that need it. This makes it less of a
sledgehammer.
|
|
trustless-remote-builder-simple
|
|
|
|
Deduplicate string literal rendering, fix 4909
|
|
trustless-remote-builder-simple
|
|
This is somewhat hacky fix just for 2.15. I unintentionally hid them
from the manual, when no one wanted to hide them that (including
myself). I also required the experimental feature to be enabled in an
order-dependent way, which is not good.
The simplest fix for this immanent release is just to always show them,
and always allow them to be set.
Effectively undoes some changes from aa663b7e89d3d02248d37ee9f68b52770b247018
|
|
Fix the flaky `nix-profile` test
|
|
|
|
trustless-remote-builder-simple
|
|
trustless-remote-builder-simple
|
|
|
|
trustless-remote-builder-simple
|
|
Also refine `nix derivation show`'s docs very slightly.
|
|
|
|
This function returns true or false depending on whether the Nix client
is trusted or not. Mostly relevant when speaking to a remote store with
a daemon.
We include this information in `nix ping store` and `nix doctor`
Co-Authored-By: John Ericson <John.Ericson@Obsidian.Systems>
|
