Repeated v2-configure floods working directory with cabal.project.local files.

[Fuuzetsu]

Describe the bug

Every time cabal v2-configure --verbose=0 is ran, a new cabal.project.local file is created with the old one being moved to a new filename. This can very quickly flood the current directory which is especially annoying in IDE file explorers and such.

To Reproduce
Go to any cabal-capable Haskell project. Run

$ ls -lh cabal.project*
ls: cannot access 'cabal.project*': No such file or directory

$ cabal v2-configure --verbose=0

$ cabal v2-configure --verbose=0

$ ls -lh cabal.project*
-rw-r--r-- 1 shana nogroup 33 Nov 25 09:26 cabal.project.local
-rw-r--r-- 1 shana nogroup 33 Nov 25 09:26 cabal.project.local~

The problem is made worse by the fact that the contents of each of these files is the same

$ for f in cabal.project.local*; do echo $f; cat $f; done
cabal.project.local
verbose: 0
ignore-project: False
cabal.project.local~
verbose: 0
ignore-project: False

I have tried adding verbose: 0 (not what I actually want though) and ignore-project into cabal.project file but the file is made regardless.

Expected behavior
My wishlist:

• allow a flag which stops the cabal.project.local file from being created at all
• if the file we're overwriting with is the same, don't make a new copy

System information

Linux aya 5.4.70 #1-NixOS SMP Wed Oct 7 06:01:31 UTC 2020 x86_64 GNU/Linux
cabal-install version 3.4.0.0
compiled using version 3.4.0.0 of the Cabal library 

I'm using the 3.4-rc4 commit of cabal-install: 81fd8d9

Additional context
My use-case for running configure so many times is that we use a Shake-based build system to build our code but use cabal to provide all the dependencies. This means that we need the plan.json file to be present and up to date and so run v2-configure for it. Likewise, this file is needed for cabal-cache to work. I want to pass --verbose=0 in configure stage only as I don't want to see the full configure output in middle of other messages from the build system. I can try to limit how often the configure is ran but the problem remains in that very quickly working directory ends up full of cabal.project.local~N files. I could remove these after running configure but that seems potentially wrong lest we do actually want to put some extra flags in there.

[phadej]

The backup logic is introduced in #6877, because when v2-configure is run by human, creating backups is justified. If run by machine, it can mitigate. (E.g. remove existing cabal.project.local file beforehand).

Alternatively you may introduce a flag to not backup. I won't accept changing the default.

[Fuuzetsu]

when v2-configure is run by human, creating backups is justified.

Justified, yes. But it makes no sense to litter the directory with identical files, no matter if human runs the configure or machine.

If run by machine, it can mitigate. (E.g. remove existing cabal.project.local file beforehand).

That just means we're basically reverting #6877 and if someone did change cabal.project.local before machine ran, it gets deleted…

Anyway, I'm not suggesting changing the default, just would love a flag that stops the file from being output all together. When making backups, it shouldn't make identical copies, this just seems like oversight.

[phadej]

It always create a backup. It's simple and predictable behavior. If you don't want/need backups, add a flag.

[Fuuzetsu]

It always create a backup. It's simple and predictable behavior. If you don't want/need backups, add a flag.

I may want backups. I don't want same file 50 times. The whole point of the backup was to not lose any custom user stuff that may have been added, not to make a new file for the sake of it.

[jneira]

My two cents: dont copy again if contents are exactly the same seems quite predictable to me and only slightly less simple.
Would it have any concrete drawback?, i dont think any actual workflow would be broken with that change

[phadej]

Adding a flag to not do backup at all is independent of "smarter backup" . This issue is about former, as far as I understand. I'm not confident of making backup smarter, as that's an issue where bugs shouldn't exist (otherwise a user may be very angry).

[yaitskov]

I suffer from this feature too. I think making backups is an obsolete approach predating version control system. If this file is really important to developer he would commit/stash current state.

[yaitskov]

So why not autocommit this file before changing instead of make backups?!

[phadej]

cabal.project.local is not meant to be in VCS, this is why it's called cabal.project.local. If you want to commit configuration (for everyone) use cabal.project.freeze (either generated by cabal v2-freeze or manually created or both).

EDIT: I don't see why you would do repeated cabal configure. Why you would do that? If you are writing the script, just repeat the arguments to v2-build, v2-test etc.

[yaitskov]

I see. Did anybody suggest to keep backups in a sub folder?
I guess this compromise will satisfy both sides.

[Fuuzetsu]

EDIT: I don't see why you would do repeated cabal configure. Why you would do that? If you are writing the script, just repeat the arguments to v2-build, v2-test etc.

There was one given in the OP: getting up to date plan.json file for cabal-cache or any other tool, rather than jumping straight to build with cabal v2-build.

[fgaz]

getting up to date plan.json

cabal v2-build --dry

[Fuuzetsu]

cabal v2-build --dry

Hm. If this works then great. Indeed I'm looking at v2-configure docs and it just says:

cabal v2-configure is intended to be a convenient way to write out a cabal.project.local for simple configurations;

So if cabal v2-configure is completely optional even on the first run if we don't care about cabal.project.local then that completely side-steps this whole ticket for me and allows me to remove hacks to delete cabal.project.local.

[fgaz]

So if cabal v2-configure is completely optional even on the first run if we don't care about cabal.project.local then that completely side-steps this whole ticket for me and allows me to remove hacks to delete cabal.project.local

This is correct. If necessary, v2-build autonomously generates a build plan, and does not need any preparatory command

[Fuuzetsu]

@emilypi could you describe how #7402 addresses this particular issue? I'm not saying it doesn't – but it's a big MR and it's hard to tell: at first glance, one might think that this issue getting closed means that cabal v2-configure won't make spurious back-ups anymore but I don't think that's what #7402 actually does.

[ptkato]

#7402 changes v2-configure so it makes only 1 backup by default, while also adding a flag --enable-backup/--disable-backup to control whether or not the backup feature should be enabled.

[Fuuzetsu]

Awesome, thank you!