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
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>
Now that we're using nixpkgs 24.11 it's possible to build cross
for FreeBSD from linux, both in a derivation and a devShell.
Change-Id: I06fa257023397a97cdc72af51170e8523e9f1bfb
This feature allows calling external binaries starting with `lix-` as
subcommands directly within the `lix` CLI, similar to how Git handles
external commands.
For example, a binary named `lix-example` can now be invoked using `lix
example`.
This change opens up the possibility for broader community-driven
extensions of the Lix CLI, offering flexibility that Flakes has somewhat
restricted by centralizing certain features around its own model of
dependency management.
By enabling users to introduce custom subcommands, we encourage
experimentation and diverse workflows, addressing the needs of those who
seek more modular, feature-rich approaches to package management and
system configuration beyond what Flakes currently offers [1] [2] [3].
This adds `lix` as a new binary to be able to use this feature.
[1]: https://github.com/nmattia/niv
[2]: https://github.com/andir/npins
[3]: https://github.com/nikstur/lon
Change-Id: Ic6344424a6a46fc9fb30432f00e21c3509659f8a
Signed-off-by: Raito Bezarius <raito@lix.systems>
This is mostly to deal with fatal errors in NixOS tests, but it's useful
for all cases; assertion failures landing in syslog would be nice too,
but that's not as easy to do.
CC: https://git.lix.systems/lix-project/lix/issues/693
Change-Id: I6b5bd9800db3f5affe33f2946ea218e4a78f0c07
This also adds documentation for it in distributed-builds.md as that's
possibly the most common use-case for remote ssh stores
Support for `std::optional<uint16_t>` in Setting is also added since
setting a port is optional.
The line `#include "lix/libutil/strings.hh"` fixes that templates instanciations
in lix/libutil/config-impl.hh were using string utils without including
the header (why are they even there btw)
Change-Id: Id806c117c48cdf158d9d1cb1e639b0df31d9bf11
The lix daemon wants to avoid orphan processes outliving a lix build.
In order to do that it kills all processes under the build user's UID
after and before a build.
When using sandboxes under Linux, this is unecessary, as builds are run
inside a PID namespace, which guarantees that processes cannot outlive
the "init" process.
Partially fixes https://git.lix.systems/lix-project/lix/issues/667
Change-Id: Idb2cdaad30169b75d730e8a18b360330516faf8b
a65e9e5828 did not inform `tryEval` that
(as far as it's concerned) `state.debug` moved to `state.errors.debug`
and changed types. this resulted in the REPL erroneously coming up, that
REPL having a non-debug state, and segfaulting after that REPL exited.
it's probably good that `state.debug` isn't mutated by `--ignore-try`
anymore.
Change-Id: I1918e93edacd626452aa423fc2eb825080738835
Fixes: a65e9e5828 ("libexpr: extract eval error creation into new type")
Signed-off-by: Dusk Banks <me@bb010g.com>
The code for serialization Expr nodes back into (pseudo-)Nix has been
removed for being subtly error-prone and tedious to maintain. Instead,
`nix-instantiate --parse` now prints a JSON representation of the AST.
Usage patterns of the --parse flag I've found in the wild:
1. Check if a file is well-formed, i.e. discard output and test exit code
2. Get parser errors from a file, i.e. discard stdout and use stderr
3. Nixfmt uses --parse to test equivalence pre/post format, and that property is (should be?) preserved
None of these should break with the current change
Closes#487
Change-Id: Icdbaad17790f2ad8765fa08e02e6597ee4c7a909
This is a breaking change for non-migrated external clients. External
users always need to use <lix/libcmd/foo.hh> type include paths now.
This is as was always planned with the include rearrangement.
Change-Id: I269be91ff9f9cc94d5d3043cf3e0bdf8db1d8edb
After gathering more community feedback, more non-trivial use cases for
overriding `__findFile` emerged. Unlike the use case of Tvix mentioned
in #599, these can't easily be worked around by overriding `nixPath`
instead.
This is the second fixup/partial revert for
81d5f0a7d9.
See also #599.
Change-Id: I7ca75e1a2b196c0da341969c61f4c168b5f657f9
Attribute names containing special characters like @ or . need to be
quoted, so we need to do our own tokenization of the command line for
completion, and quote the attribute names when we provide the completion.
Fixes: https://git.lix.systems/lix-project/lix/issues/450
Change-Id: I55a30dd272880c89445d9ded49b3f2c90cb19326
This commit makes Lix include the summarized content of the value being
indexed when it is bad.
lix/lix2 » nix eval --expr '{x.y = 2;}' 'x.y.z'
error: the value being indexed in the selection path 'x.y.z' at 'x.y' should be a set but is an integer: 2
lix/lix2 » nix eval --expr '{x.y = { a = 3; };}' 'x.y.z'
error: attribute 'z' in selection path 'x.y.z' not found inside path 'x.y', whose contents are: { a = 3; }
Did you mean a?
lix/lix2 » nix eval --expr '{x.y = { a = 3; };}' 'x.y.1'
error: the expression selected by the selection path 'x.y.1' should be a list but is a set: { a = 3; }
Change-Id: I3202aba0e437e00b4c6d3ee287a2d9a7c6892dbf
It being overridable was an intended feature with good use cases, and
should not have been removed. However, this feature is generally in a
bad state and needs revisiting in the future.
Fixup for 81d5f0a7d9Fixes#599
Change-Id: I2d93e012caa65aa795bce3a71d8e56d7052ef9df
Calls to `show` have been removed. To counter the loss of information,
the error positions have been improved and now correctly point to the
current selector instead of the entire select expression.
Change-Id: I4771fe874af1ac15828a9863550cd4369a8f0e94
The `show` functionality needs to be removed because it is deeply
flawed, and given that we already print position information in the
error message (which probably wasn't always the case in the past) the
assertion printing is redundant anyways.
Change-Id: I1f5e05ab73aaa0ec92994c2211463260fd374898
only generate-manpage.nix uses it any more, so we can inline it there
instead of keeping it around as a separate generated header. doing so
will also allow us to remove caching functions needed *only for this*
Change-Id: I97ee91f1dd7140ecb69dbafd8479b82fba7981b8
It was never intended to be a feature to be used, and moreover it is
inconsistent: One cannot override `+`, and overriding `__lessThan` won't
affect the builtins which do comparisons.
Change-Id: Iaba54a05aa4c2eb37cdb3dc0d731fcee5a86deba
clangd broke because it can't look through symlinks. compile_commands
manipulation does not fix it, clangd configuration does not fix it, a
vfs overlay does not fix it, and while a combination of those can fix
it with a bind mount in place that's just too cursed to even consider
clangd bug: https://github.com/llvm/llvm-project/issues/116877
Change-Id: I8e3e8489548eb3a7aa65ac9d12a5ec8abf814aec
Ever read gdb output and you just kinda get a headache because you have
to infer what a thread is by reading the stack trace? It's not hard, but
we could also just never have to do that again, which is also not hard.
Sample:
(gdb) info thr
Id Target Id Frame
* 1 LWP 3719283 "nix-daemon" 0x00007e558587da0f in accept ()
from target:/nix/store/c10zhkbp6jmyh0xc5kd123ga8yy2p4hk-glibc-2.39-52/lib/libc.so.6
2 LWP 3719284 "signal handler" 0x00007e55857b2bea in sigtimedwait ()
from target:/nix/store/c10zhkbp6jmyh0xc5kd123ga8yy2p4hk-glibc-2.39-52/lib/libc.so.6
The API design for this is forced by the macOS pthread_setname_np only
being able to change the current thread's name, but if we just conform
everything to that, it works everywhere.
Change-Id: I2b1d6ed41e3c94170cb0b4e73ad66f239ebd9c88
Context: we have include paths that are "types.hh" and similarly common
names. We currently have these compatibly available as
"lix/libutil/types.hh" externally but *not yet internally*. This is
because we don't have any way for the src directory to appear as
`"lix/"` from inside of Lix: the lix/ include directory is created by
the install process.
The goal of this whole thing is to make it clearer which component of
Lix that files are a part of, which should hopefully help at least a
little bit to new developers. One disadvantage of un-mixing these is
that it will cause some API changes if we ever move a file between
libraries, but that is not very common, and we don't care that much
about external API users.
This was planned for a while and is why we have a FixIncludes check to
begin with.
Personally I don't see a great benefit in rearranging our source code,
and in fact, it would probably be counterproductive:
- Moving the includes into a separate `include/` directory would just
make developers have to deal with more directories, when we can
already generate the desired layout through the build process.
- This would also decouple the .cc and .hh files which currently
conventionally have each others' definitions and declarations
respectively, right next to each other, making it easier for them to
feel decoupled and diverge.
Content: Add ../include as an include directory so that lix/ in include
paths will resolve to src/ within Lix itself, just as it does externally
today. This prepares for a further series of commits applying the actual
change to each library one-by-one by accepting both include versions at
once.
This could have been done with ../ and a symlink called lix, but we
would like to not accept libexpr/foo.hh internally for it would be
broken externally, so we need an otherwise empty directory for the
include.
Change-Id: Ideac17faadae2bcea2dffbab34eb27c582ede399
Most builtins are now generated from data too, with two exceptions:
* Undocumented builtins, since supporting them would add complexity to the
generator, the harms of the current implementation mostly don't apply, and
the proper fix is to document them.
* `derivation` is somewhat magic (it is a function, but defined in the code as
a constant), so the current treatment of having it separately documented is
kept (for now, at least).
Since it is slightly easier to do and probably a good idea anyway, the builtin
function registrations generated this way are now processed directly in code
and don't go through global variables any more.
Unfortunately, a slight breaking change is introduced because the order of the
builtins' names in the symbol table changes. Hopefully, this will turn out to
not matter in practice.
Change-Id: I7b4379a93ae380b6524e41a916a21c5c6f70555e
Currently, a bunch of documentation is generated by embedding parts of it in
the nix executable, getting it out again by running it, and then postprocessing
the output. This is bad, since it creates a pointless dependency of the
documentation on the executable, and also makes documentation generation
impossible when cross-compiling.
Instead, both the code and the documentation should be generated from data, see
https://git.lix.systems/lix-project/lix/issues/292 . Here we start applying
this approach to the experimental and deprecated features, which are done in
one go since the technical implementation is very similar.
Of course, the actual benefits are not realised yet, since the offending
pattern is used in several more places. These will be fixed later.
Change-Id: I4c802052cc7e865c61119a34b8f1063c4decc9cb
Jade Lovelace