GHCi: Handle ambiguous targets

[mrcjkb]

    TODO: Handle ambiguous targets:

e.g.,

Error: cabal: Abmiguous target: 'lib/test/Spec.hs`.
It could be:
subpackage1-spec:test/Spec (file)
subpackage2-test:test/Spec (file)

Originally posted by @mrcjkb in #13 (comment)

[mizlan]

Can we just fully qualify the file to fix this?

[mizlan]

I can't reproduce this the straightforward way it seems, is this already fixed?

[mrcjkb]

For me, the issue occurs when I'm in a cabal project that has separate test suites (e.g. subpackage1-spec for specs and subpackage1-test for integration tests, which both share the same test source directory).

-- subpackage1.cabal

test-suite subpackage1-test
  main-is: Spec.hs
  hs-source-dirs:
      test

test-suite subpackage1-spec
  main-is: Spec.hs
  hs-source-dirs:
      test

(this snippet isn't a realistic example - in practise you would have different main modules, and some other shared module in the test directory causing the error., but it should be enough to reproduce the error).

Fully qualifying the file name doesn't solve the issue, unfortunately.
So a solution might be to either parse the package file (*.cabal or package.yaml) - which would be a pain in Lua, or to somehow query cabal/stack.

This is probably a rare occurrence (I happen to work with some projects that have this issue), so I'm treating it with low priority for now.

[mizlan]

In the original error it says:

subpackage1-spec:test/Spec (file)
subpackage2-test:test/Spec (file)

which seems like it is two packages within the same Cabal project. Is that accurate? Your latest comment seems to suggest a different situation.

[mizlan]

Is it valid to have two test suites in the same package that not only share the test/ directory but also the Spec.hs file itself?

[mrcjkb]

It is two different test suites in the same cabal package that share the same source directory.

[mrcjkb]

Is it valid to have two test suites in the same package that not only share the test/ directory but also the Spec.hs file itself?

Probably not. But hpack isn't intelligent enough to prevent that when generating *.cabal files from package.yaml files.

[mrcjkb]

This may be feasible to fix with the cabal and stack package file parsing logic added in #180.
In case of ambiguity, the user could be prompted which package to load.