Skip to content

fetchTree without the git status slowdown #16026

@roberth

Description

@roberth

Is your feature request related to a problem?

I've been working on lazy paths, trying to get rid of all whole-repo readdirs/reads/...
Unfortunately, the shape of fetchTree's return value does not let me avoid the functionality of git status cleanly, because the dirtyRev attribute presence requires this knowledge.
So without #4090, fetchTree must be strict in what amounts to git status.

Proposed solution

Many ways to do it.

A. Break the signature

inp?dirtyRev becomes inp.isDirty.
flakes and fetch-tree users may be confused for a while as their dirty sources don't seem dirty until they update their expressions to read isDirty.

B. Make outPath categorically lazy

Return { outPath = ...; sourceInfo = ...; }.
This is significantly more breaking, so it should probably be a "rename" considering fetchTree adoption.
The new function can also remove the need for a fetchTree { lazy = true; } param; nice and clean.

fetchPath {
  # ...
} == {
  outPath = <path value>;
  sourceInfo = {
    isDirty = true;  # !
  };
}

I'd still recommend isDirty because it makes the other sourceInfo attrs like rev shouldn't depend on it either.
The sourceInfo/outPath separation is clean IMO and an insurance policy against future dynamically-optional attributes.

C. GraphQL-inspired retrieval

Get what you ask for, and nothing more

This is annoying, but also a great fit for reproducibility as Nix evolves. Adding an attribute is never a breaking change.
Important for this issue: callers can avoid dirtyRev completely by not asking.

That said, if you take "GraphQL" to literally, you'd end up retrieving a bunch of stuff eagerly, and you might have to expose this to users in the inputs.

It should probably keep returning thunky values in those attrs whenever it makes sense, or combine it into a larger fetching strategy choice when that makes sense.

fetchTree {
  retrieve.revCount = true;
  retrieve.isDirty = true;
  url = ...;
}

Alternative solutions

yes ^

Additional context

Checklist


Add 👍 to issues you find important.

Metadata

Metadata

Assignees

No one assigned

    Labels

    UXThe way in which users interact with Nix. Higher level than UI.featureFeature request or proposalfetchingNetworking with the outside (non-Nix) world, input lockinglanguageThe Nix expression language; parser, interpreter, primops, evaluation, etcperformance
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions