`cabal configure` shouldn't overwrite a `cabal.project.local` it hasn't written so

[andreasabel]

A cabal.project.local written or changed by the user should not be overwritten by cabal configure.

See hpack for a technical solution using hashes: When it creates a cabal-file, it also stores its hash. It then won't overwrite the cabal file if its hash is no longer correct. The user has to delete the cabal file then if they want it to be updated by hpack.

[ulysses4ever]

Previous art: #6016. There should be no overwrite, but rather: rename+create.

I think the design space here is big with no obvious most-clean solution. Hashes feel kinda hacky to me. Of course, as a non user of v2-configure, I invite others to opine.

[andreasabel]

Currently cabal.project.local is backed up to cabal.project.local~ before being overwritten. This is useful, but not fully safe. E.g. if you run cabal configure twice, it will not make more backups, like ~2. Your original file will be gone than.
This is a real scenario, e.g. by pressing the up key not the correct number of times in a terminal, thus, invoking a previous command that isn't safe to invoke again.

[Mikolaj]

With v2-, I think the only purpose of configure is to save your commandline arguments as cabal.project.local file. Is the problem that people that used v1 or still use v1 make the mistake of invoking v2-configure instead of v1-configure?

[jneira]

hmm but those command CLI options could be long and hard to recollect and reproduce, cabal v2-configure gives you an option to save that valuable work (instead sabe it as a script)