This is a redesign from 9b1f3cbc13 where
this was introduced.
I deleted the AbstractConfig::toKeyValue since it was conspicuously and
obviously broken for two years since 450e5ec618.
I asked myself if anyone was using it, given that it only emitted
settings that were aliases (broken!), and found that nobody used it.
The motivation for this change is the same for only emitting overridden
settings to the protocol: the nix inside there may not be able to parse
our defaults, as is the case of CppNix since the consensual
accept-flake-config was added to Lix.
Fixes: https://git.lix.systems/lix-project/lix/issues/739
Change-Id: Ib9874a52137f1f22220c25bcfa2425a4802509c7
Missing these is really annoying, causes massive problems for debugging
(if you don't to enable build logs), and there's basically no reason we
can't just always show them.
In the future we might want to emit these to syslog/systemd/etc, but for
now let's just always print them to the console.
CC: https://git.lix.systems/lix-project/lix/issues/675
Change-Id: Ib6c47f3e34e553505298ed49c8bdb43f3db317a4
Previously, only the `install` target in the `justfile` took extra
`*OPTIONS`, which meant you could run `just build install test` (or
`just clean setup build install test` for a clean build). This is much
more convenient than `just build && just install && just test`.
However, sometimes you *do* need extra options for some of those other
targets, so over time they have gained extra arguments. But these
prevent you from chaining the targets together:
$ just clean setup build install test
rm -rf build
meson setup build --prefix="$PWD/outputs/out" $mesonFlags build install test
usage: meson [-h]
{setup,configure,dist,install,introspect,init,test,wrap,subprojects,rewrite,compile,devenv,env2mfile,reprotest,format,fmt,help}
...
meson: error: unrecognized arguments: install test
error: Recipe `setup` failed on line 13 with exit code 2
As a compromise, I've renamed the targets with extra arguments to
include a `-custom` suffix, and added aliases for the old targets to
call the `-custom`-suffixed target with no extra arguments.
This makes it possible to run `just build install test` again, but keeps
the ability to run `just build-custom EXTRA_MESON_BUILD_ARGS`.
BONUS:
- Added `test-unit` and `test-integration`, because I always forget the
arguments to run a particular test suite and the names of those test
suites.
- Added doc comments to `lint` and `lint-fix`.
Change-Id: I61ec66f5e4d38c12bbae4fa226d7b4cea94579d1
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
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
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
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
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>
Last week I was hunting a production issue at work related to CppNix and
the only hint I had was this warning. While the cause was clearly a
CppNix issue since it was related to the libgit2-backed tarball cache,
the fact that this exception was hidden, made it way harder to discover
this. It would've saved me a lot of time[1] if the error was just
printed out (and thus would've ended up in the logs).
This is what this patch results in:
$ nix-instantiate -I https://notexisting.com --find-file . --option connect-timeout 1
warning: error: unable to download 'https://notexisting.com': Resolving timed out after 1001 milliseconds (curl error code=28); retrying in 265 ms
warning: error: unable to download 'https://notexisting.com/': Connection timed out after 1002 milliseconds (curl error code=28); retrying in 523 ms
warning: error: unable to download 'https://notexisting.com/': Connection timed out after 1001 milliseconds (curl error code=28); retrying in 1324 ms
warning: error: unable to download 'https://notexisting.com/': Connection timed out after 1000 milliseconds (curl error code=28); retrying in 2670 ms
warning:
… while downloading https://notexisting.com to satisfy NIX_PATH lookup (ignoring)
warning: unable to download 'https://notexisting.com/': Connection timed out after 1001 milliseconds (curl error code=28)
/path/to/nix/path/root
The `unable to download` part was hidden before. Granted, this is not the most
interesting showcase given the retries before, but I'd still argue that
this is useful for cases where you don't have a connection timeout (and
this was just the most trivial way to test for me).
[1] Unlucky as I was, I had to mount an older backup and nixos-enter
into the mount to reproduce this.
Change-Id: If2894369fc0b159a307b448e1ce7d9b54a327df6
Starting with commit 0dbfa7b26e access would also
be allowed to ancestors of allowed paths. This is (ironically) a significant
purity regression, since several users of the purity checks will themselves
assume that arbitrary descent is allowed. For example, `builtins.readDir` and
`builtins.path` could now refer to the filesystem root, breaking purity
entirely in the latter case by allowing to read arbitrary files. Restore the
previous behaviour of only allowing access to explicitly allowed paths.
Change-Id: Ie64180733ab735da9873255e1ccbf95ba7c9161c
I've always been annoyed that it just silently succeeded without any
feedback, but now with the upcoming improvements on defining variables
this is more necessary than ever.
Change-Id: I565897fa2f97cf6f567d4449dcc8d4ad4eb73fce
I absolutely want to go back to allowing them, I am strongly of the
opinion that nothing should be special about NUL in a string, but this
will have to wait until at least the GC rewrite, so for now the least I
can do is to disarm this gun.
Change-Id: Id14b6037bc8b274c6c60ad970b1c74d436fb62a7
They are broken beyond repair, and barring a language version revision
this is our only option besides doing nothing about it.
Change-Id: I25fa4f032ca9b5ca67356946bcd889289583592e
macOS uses opendirectory for users and groups, which supports nested
groups and groups with synthesized membership. This means that asking
for a group's users isn't sufficient to test for group membership.
With this change, groups like `@localaccounts` or `@_developer` will
work in `trusted-users` and `allowed-users`.
Fixes https://github.com/NixOS/nix/issues/5885
Change-Id: I3b0783ce7cec303de5aba32c8e5ac0f976112c72
This is necessary to cleanly and unambiguously transition to using
forgejo issues, since we now control our own destiny.
If we ban unprefixed numbers for a couple of releases, we ensure there
are no releases in active support with the wrong unprefixed number
semantics that could receive backports.
Change-Id: I1c94541dcb3f071399f439870b48cd76557b70d2
Backport of https://github.com/NixOS/nix/pull/12275
nix-env can read priorities from a derivations meta attributes, but this
only works when installing a nix expression.
nix-env can also install bare store paths, however meta attributes are
not readable in that case. This means that a store path can not be
installed with a specific priority.
Some cases where it is advantageous to install a store path: a remote
host following a `nix copy`, or any time you want to save some
evaluation time and happen to already know the store path.
This PR addresses this shortcoming by adding a --priority flag to
nix-env --install.
Change-Id: Ibd9365d0058820a9c2aeecc909b81a0410d5764b
Under chroot or diverted store setups, the filtering logic of
`builtins.filterSource` and `builtins.path` (which shares the same filtering
logic as `filterSource`) would incorrectly pass physical paths to the
filter function instead of logical store paths.
This caused actual breakage in nixpkgs when the `lib.fileset` library was
introduced. Due to this unresolved bug in Nix, the library was forbidden
from use: <https://github.com/NixOS/nixpkgs/pull/369694>.
To the best of our knowledge, this bug has existed since CppNix 2.3.
The existing tests were strengthened to cover these cases, but
additional testing may be required, particularly regarding symlink
handling.
References: https://github.com/NixOS/nix/pull/12512 (CppNix fix to the
problem using "union" abstractions).
Co-authored-by: Raito Bezarius <raito@lix.systems>
Co-authored-by: Alois Wohlschlager <alois1@gmx-topmail.de>
Co-authored-by: eldritch horrors <pennae@lix.systems>
Signed-off-by: Raito Bezarius <raito@lix.systems>
Change-Id: Iaf6ca8c506eeca145393ce100c64db12178daa62
Let's use similar terminology and formatting to the other entries,
and make it a bit clearer.
The information here is based on the changelog entry from when this
feature was added.
Change-Id: Ia859c710588180ca827c665a70650eb4db5a1c45
There's no reason to make it dependent upon `Xp::Cgroups`, this
increases the purity of the builders' views.
Change-Id: I3d934428177e6bb78cd700d1cce1ded8a88e9da0
Signed-off-by: Raito Bezarius <raito@lix.systems>
Mario Rodas