feat(nix): export lib.nativeOverlays, so consumers stop naming overlays - #11
Merged
Conversation
A consumer doing its own `import nixpkgs { overlays = ...; }` currently has to
name each overlay it wants. That is how the importCargoLock fix reached master
applying to nothing: logos-module-builder's mkPkgsWith takes a bare
`import nixpkgs`, and the one open PR wiring it (logos-module-builder#220)
names `fetchCargoVendorUserAgent` alone — the wrong fetcher for module builds,
which vendor through `cargoLock` and so through importCargoLock.
Export the list this flake already keeps internally. A consumer writes
overlays = logos-nix.lib.nativeOverlays ++ ownOverlays;
and a future overlay reaches it with no consumer change. `lib.overlays` stays
as the menu, for anyone who genuinely wants one. Windows overlays are not in
the list and must never be: they belong to a cross set only.
checks.<sys>.overlay-exports guards the bookkeeping. `lib.overlays` and
`lib.nativeOverlays` are maintained by hand and nothing tied them together, so
adding to one and forgetting the other reproduces the original bug exactly.
Nix cannot compare functions, so the gate compares counts: it fires in both
directions and names the offending entries. Verified by simulating a third
overlay added to `lib.overlays` alone:
overlay export drift: lib.nativeOverlays has 2 entries but lib.overlays
lists 3 non-Windows overlays (fetchCargoVendorUserAgent
importCargoLockStaticCratesIo somethingNew)
That new gate also changed what M4 in the mutation suite catches: dropping the
overlay from `nativeOverlays` is now reported as export drift, before any crate
URL is examined. Split it so both paths stay covered — M4 drops it from
`nativeOverlays` only, M6 from both, and each asserts its own message. Suite is
7/7.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Sep 8, 2026
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Enabler for the logos-module-builder wiring, which is the consumer line that actually
unblocks Rust module builds.
Why
A consumer doing its own
import nixpkgs { overlays = ...; }has to name each overlay.That is precisely how #9 reached master applying to nothing:
logos-module-builder'smkPkgsWithis a bareimport nixpkgs, and the one open PR wiring it(logos-co/logos-module-builder#220) names
fetchCargoVendorUserAgentalone — the wrongfetcher for module builds, which vendor through
cargoLock, henceimportCargoLock.Naming overlays one by one means every future overlay repeats that. So export the list
this flake already keeps internally:
lib.overlaysstays as the menu for anyone who genuinely wants a single one. TheWindows overlays are deliberately not in the list — they belong to a cross set only.
The bookkeeping gate
lib.overlaysandlib.nativeOverlaysare both maintained by hand and nothing tiedthem together, so adding to one and forgetting the other reproduces the original bug.
checks.<sys>.overlay-exportsguards it. Nix cannot compare functions, so it comparescounts — which fires in both directions and names the entries. Verified by simulating a
third overlay added to
lib.overlaysalone:Mutation suite
The new gate changed what M4 catches: dropping the overlay from
nativeOverlaysis nowreported as export drift, before any crate URL is examined. Split so both paths stay
covered — M4 drops it from
nativeOverlaysonly, M6 from both, each asserting its ownmessage. Suite is 7/7, and
nix flake check --no-build --all-systemsexits 0.🤖 Generated with Claude Code