Fixes these warnings:
[WARNING] hook id `check-executables-have-shebangs` uses deprecated
stage names (commit) which will be removed in a future version.
run: `pre-commit migrate-config` to automatically fix this.
Change-Id: Iab7d35999244df0eb4c32541b1f9c6a2dc2f3e28
Once I add `registerNixDaemon` and similar for the new-style commands,
they'll conflict with the old `register*` functions, so let's add
`legacy` to their names.
Change-Id: I3fc0f15985abe43bc1f257be3ebd9021b66055a3
This name made sense at the time, but now I'm looking at making the
corresponding change to `CommandRegistry`, and I don't think `Commands`
is a good name for _that_ type, but I don't want the types to be
mismatched, so here we are.
Change-Id: I06068cbde00f49ff3d720c505a567a152b00b61c
This sorts lines alphabetically between `keep-sorted start` and
`keep-sorted end` markers.
See: https://github.com/google/keep-sortedCloses#730
Change-Id: Ib36f3da81fcf5e2f588ffb998860456405607eea
Right now, Lix waits for quite a while five times[1] if a substituter is
down. If the substituter is not reachable for that long, it's probably
down or so slow that it doesn't make sense to download from it. Also,
most people would abort earlier assuming that Lix just behaves weird in
that case.
Reducing the timeout to 5s to make the behavior a little better.
If people live in areas with poor connection where a higher timeout
would be appropriate, I'd argue that they should increase the timeout
rather than requiring everbody else to set it to a non-zero value.
Additionally, communicate how often we're re-trying.
[1] Because of `download-attempts` from `nix.conf(5)`
Change-Id: I8500dce0c8230247dd492e43cc7af4d3b58c4710
Closes#703
The problem boils down to:
* A testcase with a segfaulting worker due to a stack overflow from the
evaluation.
* When the controller encounters that the pipes are down, the worker's
state is checked and a potential infrec is reported if it stopped with
SIGSEGV.
* However, in a few cases, the worker didn't exit yet, but only had closed
pipes (which is how the error is detected). In that case, a different
error message is printed breaking the test.
This bug handling only affects error cases, so this race doesn't happen
on normal shutdown. To mitigate the problem a bit, the controller will
wait for a second and re-check the state of the worker process then.
While this should make the error reporting for end-users a little more
reliable, it's still no guarantee for a non-racy test. Hence, the test
asserts against both cases now and it passes if either the infrec error
or the "worker still running, but pipes are closed" error is returned.
Change-Id: Ifdc7a05bc86b6aecd5d03118d3e3ffc9affe1c5e
This is to some extent a simple transliteration of bench.sh, but also
adds some additional features:
- the ability to select which benchmarks to run, instead of having to
run all at once (via --cases option)
- help text (--help), and argument parsing
- ability to profile instruction counts (via --mode icount).
Instruction count is a stable metric, that correlates to the execution
time, but is less affected by the environment (like other heavy programs
running, or the system hardware).
Other projects (most notably rustc) use instruction count as a primary target metric.
Change-Id: I791cac499e64983efb8bcd4ea1faef13ded09ee6
spawning threads is not free. reusing threads is also not free, but a
lot cheaper than spawning now ones. the difference can add up quite a
bit on nixos system evaluation; we've seen 20k threads cycled through
on even modestly sized configurations, and at 20µs per thread just to
launch and tear down (excluding any work done) that's potentially not
insignificant. in our test config this was a 3% eval time difference.
Change-Id: I40f901813e700fb99f5def82da54ca969711961b
The repl crashes with an assertion error at lix/libutil/file-system.cc:45
if you run ':log' without any derivation, so I added a check to error out
gracefully
Change-Id: I7af70040f884e905f0514ea9883b2380fe148f15
When lastModified comes via inputFromAttrs it ends up as string in the
Attrs map. This results in:
error: input attribute 'lastModified' is not an integer
Fix by handling it like revCount, which already does the right thing.
If added a test and confirmed that it catches the issue.
Also kudos to alexander.sieg@cyberus-technology.de for helping with
debugging this!
Change-Id: I8378fcaea986d798cb8458d4e6e15c2a92c2520a
After the release is created, we do some post-release validation for the
Lix packaging in Nixpkgs. This change documents those checks.
NB Most of these should probably be *pre*-release validation checks!
Closes#627.
Change-Id: I773e703582ccc8349987abd1e860a189a437cf3b
This adds a gcTryDeleteSpecific operation. This is similar to
gcDeleteSpecific, but will not fail if any of the given paths cannot
be deleted. Paths that could not be deleted are reported in the new
`kept` field of struct GCResults.
This also changes the behaviour of gcDeleteSpecific, such that it will
now continue deleting paths even if it fails to delete one along the
way, and only throw an error once deletion of all the given paths has
been attempted. This seems reasonable to me, because it makes its
behaviour somewhat less surprising -- previously, if some paths were
deletable and others weren't, the deletable ones would be deleted iff
they preceded the live ones in lexical sort order.
This also fixes a regression introduced in
8614cf1334, whereby nix-store --delete
failed to delete paths if they had any dependents -- even if none of
the dependents had GC roots.
The gcTryDeleteSpecific operation is surfaced via additional flags for
the `nix store delete` and `nix-store --delete` commands.
This makes custom garbage-collection logic a lot easier to implement
and experiment with:
- Paths known to be large can be thrown at `nix store delete` without
having to manually filter out those that are still reachable from a
root, e.g.
`nix store delete /nix/store/*mbrola-voices*`
- The --delete-closure option allows extending this to paths that are
not large themselves but do have a large closure size, e.g.
`nix store delete /nix/store/*nixos-system-gamingpc*`
Having an option for this is not strictly necessary, but convenient
because it doesn't require the user to add an extra `nix-store
-qR` (or `nix path-info -r`) into their command, nor to rewrite
their command to use `--stdin` if the closure ends up too large to
fit on a command line.
- Other heuristics like atime-based deletion can be applied more
easily, because `nix store delete` once again takes over the task of
working out which paths can't be deleted.
Change-Id: If345407fe7b11bdb3a8fdc04b0d56c32ab3d5928
if two derivations have different outputs of the same other derivation
as inputs there's a race window in which wanted output tracking broke:
- start building depender-a
- schedule dependency^a for depender-a
- substitute dependency^a
- dependency runs path validity checks, yields
- start building depender-b
- depender-b adds b to the wanted set of dependency
- dependency resumes from validity checks with allValid
- depender-b is unblocked, but dependency^b is not in the store
Change-Id: Id4dba517bbbdbae96bf430d2c68f63eccd3b99dd
If tearing occurs while the progress bar is rendering, flickering can occur.
This is particularly visible in multiline mode. Use the synchronized updates
specification [1] to make updates atomic on supported terminal emulators. On
unsupported terminals, the escape sequences should be ignored, leaving the
behaviour effectively unchanged (but there's nothing we could do better in this
situation).
[1] https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-updates-spec
Change-Id: Ic91ca40422c73ac9f9e088c7cb78c1b8c28adc4e
The multiline progress bar would not clear itself before writing to stdout,
leading to interference with the redraw; the most visible symptom is after
building in the repl, where the lines indicating the build outputs would be
wiped instead of the progress bar header. Separate the steps of erasing and
redrawing the progress bar, so that arbitrary output can happen in between in
a non-awkward way. In addition to fixing the bug, the code is simplified.
Change-Id: I142cf38f5ba5cd672cd6016e996b2f7bf726e9cd
well, oops. on slow io (as can happen with ssh remote builders) we could
have extended a nar read buffer past what was actually read, injecting a
span of zeroes into the read buffer where we requested some data but got
a partial result instead. also add some tests that would've caught this.
Change-Id: I67aa06b4715aeec6a5bdacaafa9b79849e664e2f
there's no real usefulness to this output in build logs. in interactive
development builds -v can be passed to meson to restore the old output.
Change-Id: Iac4c0573fd1cac5fc9044b950ef52ee50448e6fc
This replicates behaviour found in the Nix2 commands, where IN_NIX_SHELL
is set. This is for shells to determine whether they are inside of a
Nix3 shell, and set a custom prompt accordingly.
For example, Fish's Tide prompt framework checks for that environment
variable and displays it in the prompt, indicating that the shell is in
a Nix environment.
This is not new behaviour, and the old Nix2 commands set the variable.
If the shell that is created is a "pure" shell, ie --ignore-environment
is passed, then IN_NIX_SHELL will be set to "pure". However, "nix
develop" will always create an impure environment.
Replicated from my Nix PR: https://github.com/NixOS/nix/pull/8885
Change-Id: I695cdc336f76541940a302835124fe7d8f7f39b2
Signed-off-by: Ersei Saggi <vcs@ersei.net>
this reverts commit 749a323597. the pool
does hurt performance and concurreny, so let's revert now that we can.
Change-Id: I0b154cf04d14fa2cb4d2028f9cc865e463cd2265
connection pools of remote stores can currently block. this is not a
problem when each request runs on a dedicated thread, but with async
code this is no longer true. if a remote store has exhausted all its
available connections on one executor and another job starts *on the
same executor* we'll deadlock if that job makes another remote store
request. unlike with sqlite previously it's not reasonable, not even
necessary, to make the pools unbounded: since we use pools only with
remote stores we can asyncify all of them at once, and since they're
leaves of all call stacks we do not have much code to change either.
Change-Id: I8c457e27893e22c2cfc35933307a5283c986805a
eldritch horrors