| Age | Commit message (Collapse) | Author |
|---|
|
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 …
|
|
Stdenv sets this to a bash that doesn't have readline/completion
support, so running 'nix (develop|shell)' inside a 'nix develop' gives
you a crippled shell. So let's just ignore the derivation's $SHELL.
This could break interactive use of build phases that use $SHELL, but
they appear to be fairly rare.
|
|
Add example of nix develop being used to execuate a series of script
commands. This is common when doing things like CI/CD, and should be
represented in the official documentation.
Also useful for people looking for the 'nix develop' equivalent of
'nix-shell --run'.
Related:
- https://github.com/NixOS/nix/issues/6908
- https://github.com/NixOS/nix/issues/6908#issuecomment-1229266853
|
|
This was caused by -L calling setLogFormat() again, which caused the
creation of a new progress bar without destroying the old one. So we
had two progress bars clobbering each other.
We should change 'logger' to be a smart pointer, but I'll do that in a
future PR.
Fixes #6931.
|
|
nix develop: Ignore some more bash special variables
|
|
JSON: print paths as strings without copying them to the store
|
|
Fixes #6940.
|
|
after `nix eval --json` and `nix-instantiate --eval --json`.
|
|
Makes `printValueAsJSON` not copy paths to the store for `nix eval
--json`, `nix-instantiate --eval --json` and `nix-env --json`.
Fixes https://github.com/NixOS/nix/issues/5612
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
|
|
|
|
This fixes https://github.com/NixOS/nix/issues/6809
|
|
Improve shell completion of flake inputs
|
|
Defers completion of flake inputs until the whole command line is parsed
so that we know what flakes we need to complete the inputs of.
Previously, `nix build flake --update-input <Tab>` always behaved like
`nix build . --update-input <Tab>`.
|
|
flakes: apply templates partially on conflicts
|
|
Nix repl flakes
|
