C API: add logger bindings by RossComputerGuy · Pull Request #15816 · NixOS/nix

RossComputerGuy · 2026-05-08T20:48:41Z

Motivation

Closes #11036, upstreaming of DeterminateSystems#448

Context

Having Nix directly use stderr/stdout can cause problems with certain logging libraries in Rust or C. Being able to override the logger so the program integrating Nix via the C API allows for unified logging. I've tested this with Rust and it works great with tracing.

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

xokdvium

Do we not want to also expose progress in the C API?

RossComputerGuy · 2026-05-11T23:30:04Z

Do we not want to also expose progress in the C API?

Isn't that what result does?

xokdvium · 2026-05-11T23:49:55Z

Isn't that what result does?

Ah right yeah, it's a thin wrapper around result. Though we'd want to expose integer fields over the bindings as well for this to be fully usable.

xokdvium · 2026-05-11T23:53:09Z

Tbh I love this idea and the possibility of writing a C plugin that implements something like nom as a plugin. Together with #15696 this would be amazing.

RossComputerGuy · 2026-05-11T23:55:02Z

Isn't that what result does?

Ah right yeah, it's a thin wrapper around result. Though we'd want to expose integer fields over the bindings as well for this to be fully usable.

Yes, working on that.

Tbh I love this idea and the possibility of writing a C plugin that implements something like nom as a plugin. Together with #15696 this would be amazing.

That would be cool. Having a more Nix native nom would be nice, especially on systems where Haskell isn't supported.

xokdvium · 2026-05-13T16:44:49Z

+        nix::Verbosity lvl,
+        nix::ActivityType type,
+        const std::string & s,
+        const Fields & /*fields*/,


We should probably also expose the fields to the callback, since it contains valueable info about which URL is being downloaded e.t.c.

xokdvium · 2026-05-13T16:45:34Z

+        std::vector<nix_logger_field> storage;
+        storage.reserve(fields.size());


Should we maybe allocate this as a small_vector? Typically there are only a handful of fields (<4), so we could avoid the allocation overhead there completely?

xokdvium · 2026-05-13T16:47:57Z

+    uint64_t i;
+    const char * str;
+    unsigned int len;


Should this be an anonymous union with anonymous struct members? Pretty sure it wouldn't pose much of a risk to ABI backwards compatibility if we added a type of field for example (as long we only extend the union). We should also document that the size of this type could grow in a backwards compatible way.

I was thinking about that but remembered some languages with C FFI, like Zig and Dart, don't quite like anonymous struct members.

Hm maybe we can avoid the GNU extension and just do regular unions? Though I guess it doesn't matter much if it poses a compat risk

Hmm, yeah we could do a regular union we typedef. Maybe call it nix_logger_field_value.

xokdvium · 2026-05-13T16:48:57Z

+        if (fields.empty())
+            return;


Are we sure that we don't want to signal the callback even when there are no fields?

I'm not sure, I'll remove the check and we'll see.

xokdvium · 2026-05-13T16:49:18Z

+            storage.push_back(f);
+        }
+
+        std::vector<const nix_logger_field *> cfields;


Small vector would work nicely here too.

I don't see small vector in the STL docs.

We polyfill with boost's small_vector... in libexpr and other places at least

Gotcha, done

xokdvium

I guess one open question is how / whether a logger can report errors? Should it be able to or should it just swallow all errors that it might encounter internally? I guess it would be good for robustness.

xokdvium

Looking great. Now just the tiny question of error handling and how we want to address that (or whether we want to at all)

xokdvium · 2026-05-14T00:42:23Z

+                });
+        }
+
+        boost::container::small_vector<const nix_logger_field *, 1> cfields;


Could we bump the capacity to 4? That should be plenty and it's nothing in terms of stack space

xokdvium · 2026-05-14T00:42:32Z

+        if (!vtable.result)
+            return;
+
+        boost::container::small_vector<nix_logger_field, 1> storage;


Same here :)

xokdvium · 2026-05-14T00:42:45Z

+                });
+        }
+
+        boost::container::small_vector<const nix_logger_field *, 1> cfields;


xokdvium · 2026-05-14T00:42:54Z

+        if (!vtable.start_activity)
+            return;
+
+        boost::container::small_vector<nix_logger_field, 1> storage;


xokdvium · 2026-05-14T00:47:44Z

+                t = NIX_LOGGER_FIELD_TYPE_INT;
+                v.i = field.i;
+            } else {
+                continue;


Should this be an unreachable instead? If this happens it's a bug certainly...

If we think about forward compatibility, it would be the C logger's implementation to ensure that it ignores unknown values if we ever add new ones.

RossComputerGuy · 2026-05-14T18:35:38Z

I guess one open question is how / whether a logger can report errors? Should it be able to or should it just swallow all errors that it might encounter internally? I guess it would be good for robustness.

Shouldn't logEI or log handle the errors?

xokdvium · 2026-05-14T18:43:06Z

I meant the case of "nix sent garbage to the logger that it doesn't understand" and whether we need a way to provide a way to the logger to handle the case, or should it swallow all errors?

RossComputerGuy · 2026-05-14T18:45:32Z

Hmm, I think logger problems should be treated as being a non-error. Usually with what I've seen, loggers will just try their best. I think we'd have it swallow the errors.

xokdvium · 2026-05-14T23:13:56Z

Makes sense generally, though I was thinking of some sophisticated loggers that reimplemented nom that might want to do error reporting. Not sure it's worth the design complexity for the first iteration?

RossComputerGuy · 2026-05-14T23:16:28Z

For a V1, loggers could use the user data stuff to push their logging errors into wherever it should go. I'm sure this will not be the first iteration. I was just hoping this would be enough for at least basic integration.

xokdvium · 2026-05-15T00:36:28Z

Yup, we can always extend the vtable I think to add error handling if needed.

xokdvium

Hopefully the last pass of review. Looking almost perfect! Sorry for the tedious review 🥲

I guess another useful addition could be to have a way for the logger to ask nix to strip away ANSI escape sequences automatically, but that's probably good to leave for V2 iteration.

xokdvium · 2026-05-15T00:37:46Z

+                t = NIX_LOGGER_FIELD_TYPE_INT;
+                v.i = field.i;
+            } else {
+                std::unreachable();


Huh std::unreachable actually invoked UB. We have nix::unreachable to trigger std::terminate and crash though.

xokdvium · 2026-05-15T00:38:30Z

+        boost::container::small_vector<nix_logger_field, 4> storage;
+        storage.reserve(fields.size());
+        for (const auto & field : fields) {
+            nix_logger_field_type t;
+            nix_logger_field_value v{};
+            if (field.type == nix::Logger::Field::tString) {
+                t = NIX_LOGGER_FIELD_TYPE_STR;
+
+                nix_logger_field_value_string str;
+                str.value = field.s.data();
+                str.len = field.s.size();
+
+                v.str = str;
+            } else if (field.type == nix::Logger::Field::tInt) {
+                t = NIX_LOGGER_FIELD_TYPE_INT;
+                v.i = field.i;
+            } else {
+                std::unreachable();
+            }
+
+            storage.push_back(
+                nix_logger_field{
+                    .type = t,
+                    .value = v,
+                });
+        }
+
+        boost::container::small_vector<const nix_logger_field *, 4> cfields;
+        cfields.reserve(storage.size());
+        for (const auto & f : storage)
+            cfields.push_back(&f);


This can be factored out into a helper function, right? There are 2 places that do this now.

xokdvium · 2026-05-15T00:39:22Z

+ * @note Must be kept in sync with `nix::ActivityType`.
+ */
+enum nix_activity_type {
+    NIX_ACTIVITY_TYPE_UNKNOWN = 0,


Maybe NONE would be more in-line with what's documented above?

xokdvium · 2026-05-15T00:41:23Z

+    std::vector<std::tuple<
+        nix_activity_id,
+        nix_verbosity,
+        nix_activity_type,
+        std::string,
+        std::vector<CapturedField>,
+        nix_activity_id>>
+        starts;


Could this maybe just be a struct? A bunch of std::get calls with indices aren't very readable.

xokdvium · 2026-05-15T00:46:30Z

+ * @brief Replace the global Nix logger with one driven by C callbacks.
+ *
+ * After this call, log messages, activities and supported results
+ * produced anywhere in Nix are routed to the supplied callbacks.


Another cool addition would be to have a way to get the old logger back or to chain the logger (like the json one is doing, I presume that for detnixd). Also not needed for the initial implementation though :)

RossComputerGuy requested a review from edolstra as a code owner May 8, 2026 20:48

github-actions Bot added the c api Nix as a C library with a stable interface label May 8, 2026

RossComputerGuy mentioned this pull request May 8, 2026

C API: Logging callbacks #11036

Open

xokdvium reviewed May 10, 2026

View reviewed changes