--cabal-file appears not to work

[cbarrett]

Describe the bug
The --cabal-file option does not appear to be working as I expect, leading to strange behavior when cabal is invoked at the root of a GHC checkout. (NB: this is on Windows)

To Reproduce
Steps to reproduce the behavior:

Pre-requisite: have a GHC checkout at C:\ghc (I'm on branch ghc-9.0 if it matters). From within a MinGW64 shell, cd into the checkout and create dummy.cabal as below.

$ cat /C/ghc/dummy.cabal
name:          TestPackage
version:       0.0
build-type:    Simple
cabal-version: >= 1.8

library
  build-depends: base >= 4 && < 5
               , HUnit

$ cabal v2-build --cabal-file dummy.cabal
Resolving dependencies...
cabal.exe: Could not resolve dependencies:
[__0] trying: TestPackage-0.0 (user goal)
[__1] next goal: base (dependency of TestPackage)
[__1] rejecting: base-4.14.1.0/installed-4.14.1.0 (package is broken)
[__1] rejecting: base-4.14.1.0, base-4.14.0.0, base-4.13.0.0, base-4.12.0.0,
base-4.11.1.0, base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0,
base-4.9.0.0, base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2,
base-4.7.0.1, base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0,
base-4.5.0.0, base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0,
base-4.2.0.2, base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0,
base-3.0.3.2, base-3.0.3.1 (constraint from non-upgradeable package requires
installed instance)
[__1] fail (backjumping, conflict set: TestPackage, base)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, TestPackage

These commands also do not work:

$ cd /tmp; git clone https://github.com/hspec/HUnit; cd HUnit
$ cabal v2-build --cabal-file /C/ghc/dummy.cabal
Resolving dependencies...
Build profile: -w ghc-8.10.3 -O1
In order, the following will be built (use -v for more details):
 - HUnit-1.6.1.0 (lib) (first run)
Configuring library for HUnit-1.6.1.0..
Preprocessing library for HUnit-1.6.1.0..
Building library for HUnit-1.6.1.0..
[1 of 6] Compiling Paths_HUnit      ( C:\tools\msys64\tmp\HUnit\dist-newstyle\build\x86_64-windows\ghc-8.10.3\HUnit-1.6.1.0\build\autogen\Paths_HUnit.hs, C:\tools\msys64\tmp\HUnit\dist-newstyle\build\x86_64-windows\ghc-8.10.3\HUnit-1.6.1.0\build\Paths_HUnit.o )
[2 of 6] Compiling Test.HUnit.Lang  ( src\Test\HUnit\Lang.hs, C:\tools\msys64\tmp\HUnit\dist-newstyle\build\x86_64-windows\ghc-8.10.3\HUnit-1.6.1.0\build\Test\HUnit\Lang.o )
[3 of 6] Compiling Test.HUnit.Base  ( src\Test\HUnit\Base.hs, C:\tools\msys64\tmp\HUnit\dist-newstyle\build\x86_64-windows\ghc-8.10.3\HUnit-1.6.1.0\build\Test\HUnit\Base.o )
[4 of 6] Compiling Test.HUnit.Terminal ( src\Test\HUnit\Terminal.hs, C:\tools\msys64\tmp\HUnit\dist-newstyle\build\x86_64-windows\ghc-8.10.3\HUnit-1.6.1.0\build\Test\HUnit\Terminal.o )
[5 of 6] Compiling Test.HUnit.Text  ( src\Test\HUnit\Text.hs, C:\tools\msys64\tmp\HUnit\dist-newstyle\build\x86_64-windows\ghc-8.10.3\HUnit-1.6.1.0\build\Test\HUnit\Text.o )
[6 of 6] Compiling Test.HUnit       ( src\Test\HUnit.hs, C:\tools\msys64\tmp\HUnit\dist-newstyle\build\x86_64-windows\ghc-8.10.3\HUnit-1.6.1.0\build\Test\HUnit.o )

The above merely builds HUnit, even if dummy.cabal is changed to depend on e.g. http-types instead.

Works as expected (builds the dummy package)

$ mkdir /tmp/dummy; cp dummy.cabal /tmp/dummy/; cd /tmp/dummy
$ cabal v2-build

Expected behavior
If --cabal-file is specified, it should use that and not look at other files in CWD.

System information

• Windows 10 (+ msys2)
• cabal 3.2.0.0
• ghc 8.10.3

Additional context
My cabal, GHC, mingw etc. are coming from Chocolatey.

[ulysses4ever]

Expected behavior
If --cabal-file is specified, it should use that and not look at other files in CWD.

I don't think that's the intended behavior. Although there's virtually zero documentation of this flag, and it seems to have bitrotten quite a bit (e.g. it's no longer recognized by either cabal configure or cabal build), the commit that introduced it cited selection of the appropriate .cabal file among several such files in the package directory as the main use case (e507ca8). More than that, not reading files in the current directory (as you say) appears going against the way cabal-install interface is designed and used.

I suggest we close it as won't fix. There may be a feature request hiding under this ticket, which is: provide another option, e.g. --working-dir, so that cabal-install works as if it was run from the given dir. But that may be a separate issue.

There may be separate issues for a) --cabal-file being virtually undocumented, b) cabal-install's configure / build not recognizing the flag.

[Mikolaj]

I think there are other tickets (and PRs?) about using env variables for that, about changing working directory, etc., and generally about making it saner. But I think it's worth keeping this ticket, given the few serious problems with the option at hand that should be fixed until the option is replaced or in case is stays.

[philderbeast]

Using a tool like hpack or dhall-hpack-cabal for generating *.cabal files it is quite easy to change the name of the package and so end up with two .cabal files in the same folder, old-name.cabal and new-name.cabal. How stack handles this is to baulk when finding two .cabal files in the same folder (packages in stack.yaml are specified by folder).

> stack build somefolder
Multiple .cabal files found in directory /.../somefolder/:
- old-name.cabal
- new-name.cabal

I get the feeling that cabal-install has much finer grained configuration. It has flags --project-file and --cabal-file and in cabal.project we can specify packages in various ways, *, folder, folder/some-name.cabal. This could be a good time to review those two flags and decide how we want them to work with all the v2- command at least. #7241 is related.

[ulysses4ever]

See #8395.