`nix-build` fails in shallow clones on Nix 2.35 due to forcing `revCount`

[bryango]

With Nix 2.35.1, plain nix-build fails in shallow clones with the default flake-compat setup:

… while evaluating the attribute 'revCount'

… while calling the '__forceLazyFetcherAttr' builtin

error: '<REPO>' is a shallow Git repository, so 'revCount' is not available

Selecting the package explicitly by nix-build -A default does succeed.

Cause

• Lazy revCount nix#15772 made revCount lazy. For a shallow repository, fetching the source succeeds, but explicitly forcing revCount now correctly fails because the full count is unavailable.

• flake-compat merges sourceInfo into result, then exposes almost the whole result through defaultNix:

  defaultNix =
    builtins.removeAttrs result [ "__functor" ]
    // ...

  This places the lazy revCount at the top level of defaultNix. The plain nix-build examines every top-level attribute and forces each value to determine whether it is a derivation.

Consequently, bare nix-build forces revCount even when neither the selected package nor the flake outputs use it.

A real-world instance occurred in nix-community/hydra-check#105, after CI began receiving Nix 2.35.1: https://github.com/nix-community/hydra-check/actions/runs/29458017080.

Possible fix / workarounds

One option is to stop exposing the redundant top-level revCount alias through the legacy build projection:

defaultNix =
  builtins.removeAttrs result [ "__functor" "revCount" ]
  // ...

This would still preserve revCount through:

• self.revCount during flake output evaluation;
• (import flake-compat ...).outputs.revCount;
• defaultNix.sourceInfo.revCount.

On a full repository those paths would continue to return the correct count. Downstream projects can currently either:

• use nix-build -A default, avoiding the top-level scan (which we did); or
• fetch the complete Git history so revCount can be computed.

[roberth]

I've looked into the error message first, and that leads me to believe this could be alleviated in Nix, just be improving the message and it trace context.

Specifically, it seems that the error you observe would have been an error in prior releases like 3.34. Is that something you could confirm?

Regardless of 3.34 vs 3.35 differences, you could probably resolve this error by fetching a local repo non-shallowly, or by passing shallow = true; on the relevant input.
Of course that's just a workaround, and if this is indeed a regression, we should fix it accordingly in Nix.

That said, forcing revCount is slow, so a fix here in flake compat's output seems in order, as well as in Nix proper (issue 16210).

[bryango]

Thank you for the response!

Specifically, it seems that the error you observe would have been an error in prior releases like 3.34. Is that something you could confirm?

The error is only observed in github's CI as actions/checkout defaults to a shallow clone. There seems to be no error with Nix 2.34: https://github.com/nix-community/hydra-check/actions/runs/28008521223/job/82895958355. Here is a link to the workflow source highlighting the failing steps: https://github.com/nix-community/hydra-check/blob/c1e1a22e0d255dd8ea678a2e6dcfc1cc2f819805/.github/workflows/test.yml#L17-L22

Regardless of 3.34 vs 3.35 differences, you could probably resolve this error by fetching a local repo non-shallowly, or by passing shallow = true; on the relevant input.

Thank you! I have already resolved the issue downstream and it is easy to fix. I wouldn't say this is much of a "regression" 😆 It's just that the previous implementation for revCount (as well as exposing it at the top level) is not optimal, and now with the new thunk implementation we have exposed the pre-existing problem.

[roberth]

Alright, opened NixOS/nix#16212 for the Nix part.

What remains open in the context of flake-compat is removing these attributes in accordance with NixOS/nix#16210 that's the outcome of that issue.