Baffling error messages for a package not being included in the project file
Describe the bug
The error message from forgetting to include a package in the project file is positively baffling.
To Reproduce
cabal.project:
packages: .
programs/hsutils - [main●] » git clone https://github.com/dreixel/generic-deriving
programs/hsutils - [main●] » cabal v2-build lib:generic-deriving
cabal: Internal error in target matching. It should always be possible to find
a syntax that's sufficiently qualified to give an unambiguous match. However
when matching 'lib:generic-deriving' we found lib:generic-deriving
(unknown-component) which does not have an unambiguous syntax. The possible
syntax and the targets they match are as follows:
'lib:generic-deriving' which matches lib:generic-deriving (unknown-component),
:pkg:lib:lib:lib:file:generic-deriving (unknown-file)
Please use version-prefixed commands (e.g. v2-build or v1-build) to avoid ambiguity.
Expected behavior
I would like an error message that says somewhere in it "Perhaps you forgot to add the package to cabal.project".
System information
- Operating system macOS 12.5.1
programs/hsutils - [main●] » cabal --version
cabal-install version 3.6.2.0
compiled using version 3.6.3.0 of the Cabal library
programs/hsutils - [main●] » ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.2.4
Additional context Add any other context about the problem here.
Forgive me being dense: what exactly is missing that cabal complains about? Is it just the matter of your cabal.project file not being inside the generic-deriving directory but one level up?
Correct; this uhh weird emergent use of cabal, we'll call it, is described in this post: https://jade.fyi/blog/nix-hls-for-deps/ under the subheading "yolo method".
I use this regularly at work to deal with working on dependencies alongside the main project, in order to get cabal to build them in place of the nix versions, from my development tree, while also getting hls support. (since hls only works on things below the workspace directory)
I have more weird emergent uses of cabal used at work I've not yet written about, unrelated to this bug, such as the test-dev target where we circumvent the concept of packages by stuffing src and test (and sometimes libraries under active development too!) into the same test suite target.
We do that weird use of cabal in order to circumvent ghc being bad about building multiple dependent packages at once even when only a subset needs rebuild, and not letting you run in interpreted mode in ghci on multiple packages (notably also, the ghci debugger doesn't work cross package).