To avoid changing the behaviour of projects which already set supportHpack to false but inadvertently rely on plan-to-nix loading the package.yaml files, it seemed wiser to create a new project option entirely.

I think this only matters if the .cabal and package.yaml differ.

I imagine that can happen when:

• Someone forgets to update the .cabal file after modifying package.yaml.
• Someone updates .cabal file unaware there is a package.yaml.
• Someone updates the .cabal file to test something using a tool that ignores the package.yaml (then forgets to update package.yaml).

Perhaps when the builder runs hpack it should verify that the .cabal file (if it exists) is not modified.

The builder can only do that test if knows to run hpack though, so I think we still need two flags.

I think this only matters if the .cabal and package.yaml differ.

I think so as well, but it's an invariant that's almost certainly broken by a non-empty subset of Haskell packages (at least, by Murphy's law of engineering pessimestimation) so it's best to make the new feature that breaks those packages an explicit downstream opt-in rather than impose an explicit downstream opt-out.

I imagine that can happen when…
…Someone forgets to update the .cabal file after modifying package.yaml.

Personally, I think the best way to avoid this is to set up a devshell hook to run hpack when it sees the cabal file is out of date and add it to the git index to keep it from getting out of date. (Getting a list of source directories to monitor for creation/deletion and hooking to an fsnotify service would be a nice project…)

…Someone updates .cabal file unaware there is a package.yaml.

…Someone updates the .cabal file to test something using a tool that ignores the package.yaml (then forgets to update package.yaml).

And then those modifications get checked in, and then one day somebody adds a source file or something and re-reruns hpack and the modifications are clobbered. This is probably a confusing situation for a newcomer to encounter since the trace of the modifications are hidden in the diff of a file that they entrusted a tool to modify.

Perhaps when the builder runs hpack it should verify that the .cabal file (if it exists) is not modified.

Yes, that's a good idea. Does it need to go in this feature?

The builder can only do that test if knows to run hpack though, so I think we still need two flags.

Settled. Should we consolidate the module option somewhere now that it's shared between Stack and Cabal projects?

Moved ignorePackageYaml to project-common.nix which seems like a logical place.

The development documentation in docs/dev/nix-tools-pin.md seems stale. Neither the flake input nor the materialized nix-tools seem to exist, but I'm running scripts/check-materializations anyways and will push the results in a little bit.

Thanks!

Now this is merged, I think we will need to bump the static nix-tools pin https://github.com/input-output-hk/haskell.nix/blob/master/overlays/default.nix#L37-L38 (used on x86_64-linux systems).