This was discussed as part of https://git.lix.systems/lix-project/lix/issues/767
with a one month long comment period.
This commit removes the recursive-nix feature from Lix. It has seen
limited usage and is difficult to stabilize, especially on non-Linux
systems where its behavior is underspecified.
Maintaining this feature complicates core work on the store, as we must
account for the potential presence of the daemon in the sandbox, adding
unnecessary complexity. Additionally, its inclusion in the
platform-independent local store creates risks for non-Linux platforms.
For more details on this removal, refer to the release note entry or the
issue entry.
Change-Id: I9137202f563c0a317f9c5da79cd9fd07d801427a
Signed-off-by: Raito Bezarius <raito@lix.systems>
We now properly shell out to the parser instead of hacking stuff
together with a regex. Stuff we get for free by doing this:
- Optional trailing semicolon
- Declaring nested attribute sets
- String identifiers, and future proofing for eventual grammar
improvements to identifiers
- Dynamic attributes
Change-Id: Ibf1ad815e5e27caf162df05ea5ba5b1b4955d9c9
our implementation is mostly unused, completely untested, and simply
breaks when users configure connection sharing independently. we can
safely delete this "feature" and inherit user configuration instead.
also have the remote build test check that connection sharing works.
fixes#304, fixes#644
Change-Id: Iea44cc0f8e51a1d231ad186a95c7e310bbfeb303
This reverts commit bba678e5c5.
Reason for revert: didn't fix the bug and created new ones (fj#794)
Change-Id: I0450205d3041b6c876737151a4051081c1366f1d
or more accurately, wrap them in a nix::Error subclass so we can display
them properly without crashing, and add some error context if available.
fixes#642fixes#753fixes#759fixes#769
Change-Id: I1aad0c0501fea83f9de3a1335eaa6adc20721616
* changes:
docs: document the cursed file syntax for new CLI
docs: document the cursed file syntax for old cli
doc preprocessor: support indent directives
This documents the fact that nix-build, nix-env, nix-instantiate, and
nix-shell accept an extended syntax for their file arguments, including
some well-known (but not well documented) aspects, like being able to
specify `<nixpkgs>`, but also https:// tarball URLs, `flake:` prefixed
flakerefs, and the cursed `channel:` prefixed hardcoded URLs
Same thing for the new CLI incoming :)
Change-Id: Ib6d68594a16132805ba5d97526e16f7b3633117e
allow opting in to serialization as integers via a trait type instead,
and add string-list serializers for the feature flag set enumerations.
fixes#738
Change-Id: I2746eb5ef1f15c01b4e681f9ba1615b6c6e64f44
USDT probes are statically defined trace points that have nearly zero
disabled-probe effect, i.e. we can put them in hot paths.
The use case for these is both similar and dissimilar to Rust tracing:
We still need better logging and a better structured rust-tracing
looking thing, but probes allow for quite easy programmable interactive
tracing in production, which we also care a lot about.
This CL comes with a perfunctory trace point in
libstore/file-transfer.cc for reading data out of the curl buffer. This
was mostly thrown in there so that I could see what the buffer sizes of
this were, and maybe be able to instrument the perf of the curl usages
in Lix in the future.
Fixes: https://git.lix.systems/lix-project/lix/issues/727
Change-Id: I0f5d9912d76bf3d6923bf53ebfd9b8d6c6e70aea
This is *just* in output messages that look relatively like the FOD
failure message. It's not great that we inconsistently use the old
format in random places.
Change-Id: I4b9ce73a98a3a50c924cfe1d7cded42f3756df6b
Well that is a mess. I don't like breaking derivation compatibility,
but I like non-deterministic evaluation much less.
We can break compat if we own up to it, which this does.
Fixes: https://git.lix.systems/lix-project/lix/issues/750
Change-Id: Ic9e2407393f1d42c2be604f80b4aa11bc872bc23
It's possible to put a path into the store in pure mode by pretending
it's locked like this:
$ echo 'lalala' > testfile
$ nix eval --expr '(builtins.fetchTree { path = "/home/ma27/testfile"; rev = "0000000000000000000000000000000000000000"; type = "path"; })'
{ lastModified = 1723656303; lastModifiedDate = "20240814172503"; narHash = "sha256-hOMY06A0ohaaCLwnhpZIMoAqi/8kG2vk30NRiqi0dfc="; outPath = "/nix/store/lhfz259iipmv9ky995rml8018jvriynh-source"; rev = "0000000000000000000000000000000000000000"; shortRev = "0000000"; }
$ cat /nix/store/lhfz259iipmv9ky995rml8018jvriynh-source
lalala
There was a fix in CppNix[1], but Puck noted that it's breaking
backwards-compatibility because
> [...] a github fetch with a fully specified rev is no longer considered "locked"
> this is for "purity" reasons, but it breaks any existing flake.nix files
I tried a way smaller correctness fix here:
* Each scheme can denote whether a `rev` is enough to consider itself
locked.
* If a `rev` is given and the scheme is OK with just a `rev` to be
locked, the input is marked as locked.
For `path` this is not the case anymore, i.e. it requires a NAR hash to
be locked down.
[1] https://github.com/nixos/nix/commit/071dd2b3a4e6c0b2106f1b6f14ec26e153d97446
Change-Id: Ibbbf4733c82bcfa1c24dfe099a896d8aaecd81cc
Documenting fetchTree is an exercise in frustration because of the sheer
amount of stringly typed everything in it. I do not know which fields
exist without reading the entirety of libfetchers. However, we can write
something slightly perfunctory but at least perhaps somewhat helpful
documentation-wise.
Fixes: https://git.lix.systems/lix-project/lix/issues/609
Change-Id: I991391b53fcd69172dbc7efb9d384e62bc847b91
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
Raito Bezarius