cabal icon indicating copy to clipboard operation
cabal copied to clipboard

`cabal install` prints unhelpful error when .cabal filename does not match the package name

Open falsifian opened this issue 4 years ago • 10 comments

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 avatar Mar 09 '21 03:03 falsifian

@falsifian thanks for reporting the error which i can reproduce with last cabal-3.4.0.0 Points to consider:

  • cabal v2-build lets 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 install generates 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 check tell 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 check in an error for cabal install and cabal build
  • Fix cabal install to match the behaviour of cabal build and not throw an error only for local tars generated by cabal install itself, i guess it will be tricky
  • Throw an error in cabal install using the same code cabal check uses 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 avatar Jun 13 '21 01:06 jneira

@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 :)

falsifian avatar Jun 21 '21 15:06 falsifian

As a easier to do improvement, we could improve the actual error message, without touching actual semantics

jneira avatar Nov 08 '21 20:11 jneira

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:

  1. The main concern, as pointed out by @ulysses4ever , is whether this breaks existing workflows or not. What are the options to mitigate that?
  2. Should the changed behaviour hidden behind a feature flag? Alternatively: Should there be an option to restore the old behaviour?
  3. Should there be a warning when the renaming happens?

mmhat avatar May 06 '25 17:05 mmhat

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?

mpickering avatar May 21 '25 09:05 mpickering

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.

ulysses4ever avatar May 21 '25 14:05 ulysses4ever

If I understand that issue correctly, that would require a hackage-server modification?

geekosaur avatar May 21 '25 14:05 geekosaur

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-server modification?

@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?

mmhat avatar Jun 10 '25 14:06 mmhat

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.

geekosaur avatar Jun 10 '25 16:06 geekosaur

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.

ulysses4ever avatar Jun 10 '25 17:06 ulysses4ever