cabal init --overwrite: openFile: app/Main.hs: does not exist (No such file or directory)

[fgaz]

Describe the bug
cabal init --overwrite: openFile: app/Main.hs: does not exist (No such file or directory)

To Reproduce
Steps to reproduce the behavior:

$ cabal init -n
[...]
$ cabal init -n --overwrite

Log: Guessing dependencies...

Log: Using cabal specification: 3.0

Warning: unknown license type, you must put a copy in LICENSE yourself.

Log: CHANGELOG.md already exists. Backing up old version in CHANGELOG.md.save0

Log: Overwriting file CHANGELOG.md...

Log: /tmp/tmp.ndqJzZ9Tz3 already exists. Backing up old version in /tmp/tmp.ndqJzZ9Tz3.save0

Log: Overwriting directory .//tmp/tmp.ndqJzZ9Tz3...
/tmp/tmp.ndqJzZ9Tz3/app/Main.hs: openFile: does not exist (No such file or directory)

Please use version-prefixed commands (e.g. v2-build or v1-build) to avoid ambiguity.

Expected behavior
no error, the existing .cabal file is overwritten

System information

• cabal 3.8.1.0-rc1

cc @emilypi @ptkato

[fgaz]

by the way, i found it surprising that cabal init --overwrite changes the working directory to $PWD.save$n. I think we should at least add a message informing the user of what happened. Or wasn't it supposed to do that?

[ptkato]

by the way, i found it surprising that cabal init --overwrite changes the working directory to $PWD.save$n. I think we should at least add a message informing the user of what happened. Or wasn't it supposed to do that?

It is, due to #7873.

cabal/cabal-install/main/Main.hs

Line 921 in 87bfc00

withCurrentDirectory projectDir initAction'

[emilypi]

Adding a message would be quite easy, since this is desirable behavior that just needs some information attached. @ptkato do you want to add the PR for that or should I?

Additionally, I notice the log outputs are fucked up for -n. There's lots of space. Mind fixing that too? Additionally, if we're logging, Log: is not a good prefix. Generally a formatted prefix like [LOG] and [WARN] that clearly denotes the log in opposition to the message is good UX.

[ptkato]

That message stuff doesn't seem right, it is already like that, kinda:

cabal/cabal-install/src/Distribution/Client/Init/Types.hs

Lines 360 to 362 in 5a8e997

	message q severity msg
	| q == silent = pure ()
	| otherwise = putStrLn $ "[" ++ show severity ++ "] " ++ msg

[emilypi]

Yeah, i thought i updated that already and assumed there was something different for cabal init -n. @fgaz were you using an up to date binary?

[fgaz]

@emilypi you're right, I mixed up my binaries. the spacing is fine, but the error is still there:

$ cabal init -n --overwrite
[Log] Guessing dependencies...
[Log] Using cabal specification: 3.0
[Warning] unknown license type, you must put a copy in LICENSE yourself.
[Log] CHANGELOG.md already exists. Backing up old version in CHANGELOG.md.save0
[Log] Overwriting file CHANGELOG.md...
[Log] /tmp/tmp.mIDj7MFEZ1 already exists. Backing up old version in /tmp/tmp.mIDj7MFEZ1.save0
[Log] Overwriting directory .//tmp/tmp.mIDj7MFEZ1...
/tmp/tmp.mIDj7MFEZ1/app/Main.hs: withFile: does not exist (No such file or directory

[ptkato]

There are a few weird behaviours at play here. I remember discussing about allowing only 1 backup at a given time, instead of having multiple of them, for example if we run cabal init several times we would end up with the single .save file, did we ever act upon that? I can't really remember.

Also, the overwriting does not like when used in conjunction with the "new project directory" feature from #7873, it writes the new files into the backed up directory, instead of the new one, due to how the backing up works. Should we disallow the usage of the directory extra argument with overwrite, or should we do something else?

[ptkato]

All in all, the backup feature is being a bit disruptive considering all the rest, I propose that we move that functionality from within the inner bowels of the cabal init file writing to more of a upper level, and instead of backing up each single file (as it is now it tries to do the backup "atomically", covering each file and directory individually, I don't remember the reasoning behind this), backup the whole project directory at once before we even get into the overwriting portion of the process proper. That will also help to cut down a bit on the unit-tests, and we'll be able to move the testing of that feature to cabal-testsuite more reliably.

Any objections? What are your thoughts?