Skip to content

stack: prefer a committed .cabal over re-running hpack (#626, #767) - #2547

Open
hamishmack wants to merge 1 commit into
masterfrom
hkm/issue-626-767-stack-prefer-cabal
Open

stack: prefer a committed .cabal over re-running hpack (#626, #767)#2547
hamishmack wants to merge 1 commit into
masterfrom
hkm/issue-626-767-stack-prefer-cabal

Conversation

@hamishmack

Copy link
Copy Markdown
Collaborator

Summary

In the stack path, findCabalFiles UsePackageYamlFirst (nix-tools/nix-tools/lib/Stack2nix/Project.hs) unconditionally re-rendered a package.yaml through hpack whenever it existed — even when the package directory also contained a committed .cabal file. This discards the committed file and historically failed outright with errors like ".cabal was generated with a newer version of hpack, please upgrade" (#626) or ".cabal was modified manually, please use --force" (#767).

The cabal path already prefers a committed .cabal (lib/call-cabal-project-to-nix.nix skips hpack for a package.yaml when a .cabal exists — "Ignoring $hpackFile as $cabalFile exists"). This change mirrors that policy in the stack path: use the on-disk .cabal when present, and fall back to hpack only when there is no .cabal. --ignore-package-yaml (IgnorePackageYaml) continues to force cabal-only discovery.

Tests

Adds a self-contained test-suite stack-project-tests (only touches a temp dir — no external tools, no network, no extra test-framework deps) asserting that findCabalFiles:

Verification

  • Reviewed control flow for both branches (.cabal present vs. absent); the missing-dir / no-package.yaml behaviour is unchanged.
  • cabal check passes (only pre-existing PVP upper-bound warnings, unrelated to this change).
  • I did not compile nix-tools from source: it pins ghc-9.6 and needs the full hnix/Cabal closure, which isn't feasible in this environment. The new test compiles/runs under CI rather than something I executed locally.

Notes

  • Release-gated: haskell.nix consumes nix-tools as a prebuilt static release binary, so this fix reaches haskell.nix builds only after the next nix-tools release is cut (cf. error in flake. #2506).
  • The identical findCabalFiles in plan2nix/Plan2Nix/Project.hs is left as-is: the cabal path already handles this at the Nix layer, and de-duplicating the two copies is out of scope here (related to the cache-module dedup theme in Drop duplicate code #1689).
  • A dedicated --use-package-yaml opt-out (to force stack's regenerate-always behaviour) was considered but skipped to keep the change minimal; it isn't offered on the cabal path either. Easy to add later if wanted.

Closes #626.
Closes #767.

In the stack path, findCabalFiles UsePackageYamlFirst always re-rendered a package.yaml through hpack whenever it existed, even when the package directory also contained a committed .cabal file. This discarded the committed file and historically failed outright when the .cabal had been hand-modified or was produced by a newer hpack.

The cabalProject path already prefers a committed .cabal (call-cabal-project-to-nix.nix skips hpack when a .cabal exists). Mirror that in the stack path: use the on-disk .cabal when present, falling back to hpack only when there is no .cabal. --ignore-package-yaml continues to force cabal-only discovery.

Adds a self-contained (no external tools/network) test-suite stack-project-tests exercising findCabalFiles.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

.cabal was modified manually, please use --force to overwrite. Do not call hpack if .cabal exists

1 participant