Re: 01/03: guix: store: Add ensure-path.

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

>> 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:
>
>         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);
>         }
>
> 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.

Yes but here ‘store’ is an instance of ‘LocalStore’ typically.

I’m referring to this bit in (guix nar):

  (with-store store
    (let loop ((name (temporary-store-file)))
      ;; Add NAME to the current process' roots.  (Opening this connection to
      ;; the daemon allows us to reuse its code that deals with the
      ;; per-process roots file.)
      (add-temp-root store name)

This is (I think) the only place where ‘guix offload’ connects to the
daemon, and it does so just because we don’t have an ‘add-temp-root’
implementation in Scheme.

>> 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.

Sure, but see ‘restore-one-item’ vs ‘restore-file-set’.  Perhaps
‘restore-one-item’ already does what you want.

HTH,
Ludo’.