`cabal install` prints unhelpful error when .cabal filename does not match the package name
Describe the bug
In a project where the .cabal file has underscores in the name, cabal install fails with an unhelpful error message:
dieVerbatim: user error (cabal: Package .cabal file not found in the tarball:
/tmp/cabal-install.-42328/dist-newstyle/tmp/src-42328/note-graph-0.0.0.0/note-graph.cabal
)
After much head-scratching, I realized the problem was I needed to rename note_graph.cabal to note-graph.cabal.
To Reproduce Steps to reproduce the behavior:
- Put the following in a file called
a_b.cabal.
cabal-version: 2.2
name: a-b
version: 0.0.0.0
build-type: Simple
executable x
default-language: Haskell2010
build-depends: base
main-is: Main.hs
- Put something in
Main.hs. cabal v2-install .:x
Expected behavior
One of the following would be preferrable:
- The installation works.
- Cabal prints an error like
Your .cabal file should not have underscores in the name.
System information OpenBSD current
I've got custom-built ghc and cabal-install ports; let me know if you'd like me to retry with an unmodified install.
The Glorious Glasgow Haskell Compilation System, version 8.6.4
falsifian moth d $ cabal --version
cabal-install version 3.4.0.0
compiled using version 3.4.0.0 of the Cabal library```
@falsifian thanks for reporting the error which i can reproduce with last cabal-3.4.0.0 Points to consider:
cabal v2-buildlets you build packages which .cabal file name differs from the package name described in that file (it is any difference ,not only between-and_)- but
cabal installgenerates a package.tar distribution file and then uses it to install the package like it would downloaded it from hackage. This install from a tar file needs that the .cabal file name matches exactly the package name, so it fails - that means the package will not be able to be uploaded to hackage as
cabal checktell us:
PS D:\dev\ws\haskell\cabal-test> cabal check
Warning: The filename .\cabal_test.cabal does not match package name
(expected: cabal-test.cabal)
Warning: Hackage would reject this package.
So we could do:
- Convert the warning in
cabal checkin an error forcabal installandcabal build - Fix
cabal installto match the behaviour ofcabal buildand not throw an error only for local tars generated by cabal install itself, i guess it will be tricky - Throw an error in
cabal installusing the same codecabal checkuses to print the warning
Imo the build and install behaviour should be coherent and throw an error, but if it is already a warning is cause someone would be using .cabal names different from package names locally (???). So i would vote for 2, although 3 will be easier to implement i guess
@jneira Thanks for the analysis. I don't have strong opinions or intimate knowledge of cabal, so I'll leave the discussion to others here and in #6299. I've learned the lesson already, so it's not a problem for me unless I forget :)
As a easier to do improvement, we could improve the actual error message, without touching actual semantics
While my intention was primarily to improve the workflow with name-agnostic Cabal files (e.g. package.cabal regardless of the actual package name), I accidentally implemented a fix for this in https://github.com/haskell/cabal/pull/10947:
There, the Cabal file is renamed to PACKAGE_NAME.cabal in the source distribution archive.
Would this be an acceptable solution at all? If so, then there a some open questions regarding the approach:
- The main concern, as pointed out by @ulysses4ever , is whether this breaks existing workflows or not. What are the options to mitigate that?
- Should the changed behaviour hidden behind a feature flag? Alternatively: Should there be an option to restore the old behaviour?
- Should there be a warning when the renaming happens?
It doesn't seem unreasonable to expect the sdist command to just zip up the source files of your project.
You may consume the sdist with a tool other than cabal-install, or just use it to send the source files of your project to someone else.
I think I am more in favour of an error somewhere, but then I'm not exactly sure where either. Perhaps the error message could just list out the .cabal files which could be found?
I think sdist shouldn't rename anything (re: https://github.com/haskell/cabal/pull/10947), as this would be very surprising. A more intelligent error message is enough to fix the issue as described.
If I understand that issue correctly, that would require a hackage-server modification?
Ok, thank you all for the feedback here! I am fine with just improving the error message and I could do that in a separate PR.
The discussion whether or not there should be any support for Cabal files not matching the package is then more a part of https://github.com/haskell/cabal/issues/6299 and should probably be discussed over there.
If I understand that issue correctly, that would require a
hackage-servermodification?
@geekosaur Not sure if I understand the question: Do you mean hackage-server currently accepts sdists where the contained Cabal file does not match the package name (I never tried to upload an sdist like this), and that should be changed?
No, I mean it won't accept it (Warning: Hackage would reject this package.) and I don't know if changing cabal and having Hackage use it to verify uploads is enough to change that.
I don't think Hackage itself will be an issue. But in any case this issue shouldn't block discussion and experiments: I'm sure Hackage can be dealt with if a good design is found.