Hey,
> So perhaps we should adjust the docstring to reflect that?
Sure, done with: d9e57db72479812cfa30ed8e30a6351959f9a2b2.
> Yeah, ‘guix offload’ should not connect to the daemon. It does so
> currently for one thing (registering GC roots IIRC), which should be
> done in Scheme instead.
Why shouldn't it connect to the daemon? In the current implementation of
the nix daemon, there's the following snippet:
--8<---------------cut here---------------start------------->8---
if (!missing.empty()) {
Activity act(*logger, lvlTalkative, actUnknown, fmt("copying
outputs from '%s'", storeUri));
for (auto & i : missing)
store->locksHeld.insert(store->printStorePath(i)); /* FIXME:
ugly */
copyPaths(ref<Store>(sshStore), store, missing, NoRepair,
NoCheckSigs, NoSubstitute);
}
--8<---------------cut here---------------end--------------->8---
in build-remote.cc. So it looks like it connects to the store, add the
outputs to locks held and import them, which is the behaviour I'm
trying to replicate.
> Specifically it handles “nar bundles” (new name :-)). But probably you
> can extract the relevant bits to import single nars, right?
Yup you're right, it should be possible, but I'd rater let the daemon do
it if possible.
Thanks,
Mathieu
