| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
define "store derivation"
|
|
This makes 'nix develop' set the Linux personality in the same way
that the actual build does, allowing a command like 'nix develop
nix#devShells.i686-linux.default' on x86_64-linux to work correctly.
|
|
|
|
a store derivation is not a store path itself, it has a store path.
|
|
|
|
Add anchors and links to definition
|
|
|
|
Thanks!
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
|
|
|
|
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
|
|
|
|
|
|
|
|
https://hydra.nixos.org/log/mcgypcf9vj4n8vdmw7lj3l05c899v73w-nix-2.12.0pre20221201_16b03f0-x86_64-unknown-linux-musl.drv
|
|
Fixes
error: [json.exception.type_error.301] cannot create object from initializer list
in tests/fetchClosure.sh.
|
|
Automatic UID allocation
|
|
Replace src/libutil/json.cc with nlohmann
|
|
|
|
Fix why-depends for CA derivations
|
|
|
|
why-depends assumed that we knew the output path of the second argument.
For CA derivations, we might not know until it's built. One way to solve
this would be to build the second installable to get the output path.
In this case we don't need to, though. If the first installable (A)
depends on the second (B), then getting the store path of A will
necessitate having the store path B. The contrapositive is, if the store
path of B is not known (i.e. it's a CA derivation which hasn't been
built), then A does not depend on B.
|
|
Example:
# nix build -L --extra-experimental-features cgroups --impure --expr 'with import <nixpkgs> {}; runCommand "foo" {} "dd if=/dev/urandom bs=1M count=1024 | md5sum; mkdir $out"' --json
[
{
"cpuSystem": 1.911431,
"cpuUser": 1.214249,
"drvPath": "/nix/store/xzdqz67xba18hljhycp0hwfigzrs2z69-foo.drv",
"outputs": {
"out": "/nix/store/rh9mc9l2gkpq8kn2sgzndr6ll7ffjh6l-foo"
},
"startTime": 1669024076,
"stopTime": 1669024079
}
]
|
|
|
|
|
|
Example:
# nix build -L --extra-experimental-features cgroups --impure --expr 'with import <nixpkgs> {}; runCommand "foo" {} "dd if=/dev/urandom bs=1M count=1024 | md5sum; mkdir $out"' --json
[
{
"cpuSystem": 1.911431,
"cpuUser": 1.214249,
"drvPath": "/nix/store/xzdqz67xba18hljhycp0hwfigzrs2z69-foo.drv",
"outputs": {
"out": "/nix/store/rh9mc9l2gkpq8kn2sgzndr6ll7ffjh6l-foo"
},
"startTime": 1669024076,
"stopTime": 1669024079
}
]
|
|
|
|
|
|
|
|
after discussing this with multiple people, I'm convinced that "build
task" is more precise: a derivation is not an action, but inert until it
is built. also it's easier to pronounce.
proposal: use "build task" for the generic concept "description of how
to derive new files from the contents of existing files". then it will
be easier to distinguish what we mean by "derivation" (a specific data
structure and Nix language value type) and "store derivation" (a
serialisation of a derivation into a file in the Nix store).
|
|
Move savedArgv into libmain
|
|
|
|
`savedArgv` is not accessible by plugins when defined in main binary.
Moving it into one of the nix lib fix the problem.
|
|
Fix `nix __build-remote`
|
|
Because of a wrong index, `nix __build-remote` wasn't working.
Fix the index to restore the command (and the build hook).
|
|
|
|
Fix typo -- dashes not underscores
|
|
This exposes the Store::queryPathFromHashPart() interface in the CLI.
|
|
|
|
|
|
This unclutters the per-command options a bit by moving out some
global options.
|
|
|
|
nix develop: Ignore stdenv's $SHELL
|
|
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Rune K. Svendsen <runesvend@gmail.com>
|
|
Hopefully this is best!
|
|
I just had a colleague get confused by the previous phrase for good
reason. "valid" sounds like an *objective* criterion, e.g. and *invalid
signature* would be one that would be trusted by no one, e.g. because it
misformatted or something.
What is actually going is that there might be a signature which is
perfectly valid to *someone else*, but not to the user, because they
don't trust the corresponding public key. This is a *subjective*
criterion, because it depends on the arbitrary and personal choice of
which public keys to trust.
I therefore think "trustworthy" is a better adjective to use. Whether
something is worthy of trust is clearly subjective, and then "trust"
within that word nicely evokes `trusted-public-keys` and friends.
|
|
This removes unintended blank lines in Markdown when the description
is a multiline string literal.
|
|
nix shell: document how to invoke multiple commands from the command …
|
