refactor(tvix/glue/register_in_path_info_service): return only PathInfo

The store path is already contained in the PathInfo, and the ca bits is
already passed into the function, so known to the caller - there's no
need to duplicate this.

We can also avoid having two separate block_on in our import builtin -
we already know the content hash before constructing, as we pass it in
via ca_hash.

There's still some room to unclutter some more of the code around
importing - we still do NAR calculation twice in some cases, and some of
the code might be share-able from other places producing PathInfo too.
Log a TODO for this cleanup.

Change-Id: I6a5fc427d15bc9293a396310143c7694dd2996c0
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12592
Reviewed-by: Marijan Petričević <marijan.petricevic94@gmail.com>
Reviewed-by: flokli <flokli@flokli.de>
Tested-by: BuildkiteCI
This commit is contained in:
Florian Klink 2024-10-11 01:23:00 +03:00 committed by flokli
parent 48fa320cf4
commit 6a116d5057
3 changed files with 42 additions and 33 deletions

View file

@ -77,6 +77,20 @@ correctness:
"some amount of outgoing bytes" in memory.
This is somewhat blocked until the {Chunk/Blob}Service split is done, as then
prefetching would only be a matter of adding it into the one `BlobReader`.
- The import builtins (`builtins.path` and `builtins.filterSource`) use(d) some
helper functions in TvixStoreIO that deals with constructing the `PathInfo`
structs and inserting them, but some of the abstractions where probably done
at the wrong layer:
- Some ways of importing calculate the NAR representation twice
- The code isn't very usable from other consumers that also create structs
`PathInfo`.
- `node_to_path_info` is ony called by `register_in_path_info_service` (due
to this marked as private for now).
Instead of fighting these abstractions, maybe it's best to explicitly add the
code back to the two builtins, remove redundant calls and calculations. A
later phase could then see how/if some of this can be reasonably factored out in
a way it's also usable for other places having a node and wanting to persist
it (if at all).
### Error cleanup
- Currently, all services use tvix_castore::Error, which only has two kinds