multiple components with cabal-install 3.12.1.0

[mwotton]

What happened?

carrying on from #308 - cabal-install 3.12.1.0 is out now, and the multiple component repl seems to work. unfortunately, ghciwatch crashes:

ghciwatch --command "cabal repl --enable-multi-repl mylib mylib:mylib-test" --watch src --watch test  --test-ghci main

...ghci loading elided...

Ok, 13 modules loaded.
Error:   × Tasks failed:
  │ • run_ghci: Failed to parse `:show targets` output

running cabal repl --enable-multi-repl mylib mylib:mylib-test and running :show targets, it shows my library modules and my test modules, but also 'test/Main.hs' in the list, so perhaps not surprising ghciwatch crashes if it's expecting a module name.

What did you expect to happen?

expected ghciwatch to load and run my tests.

Steps to reproduce the issue

i think you can replicate this with any library with a test component.

The version of ghciwatch with the bug

ghciwatch 1.0.1

[mwotton]

playing around with it a bit, even if i manually filter test/Main.hs, it still chokes on my test module, which makes sense given that the test source folder isn't in the search_paths at that point.

[mwotton]

(if i'm totally off-base here and there's a good workaround for having ghciwatch reload both tests and code that doesn't require multi-components, please let me know!)

[mwotton]

ah, so the current hack in https://github.com/MercuryTechnologies/ghciwatch/tree/main/tests/data/simple is to just have a single component that pulls in everything? ok, that makes sense.

[9999years]

This shouldn't crash, I'd like to support multiple components.

[eddiemundo]

Seems like the problem here is that :show paths gives only the paths for a single component and not all of the components so targets from other components can't be found.

Dunno if there is another way of finding the component paths to hack around this?

[9999years]

@eddiemundo Would you paste some example output? It'll help when I have time to look into this.

[eddiemundo]

cabal repl --enable-multi-repl component-a component-b component-c
ghci> :show paths
current working directory: 
  /home/jon/projects/my-project
module import search paths:
  src
  /home/jon/projects/my-project/dist-newstyle/build/x86_64-linux/ghc-9.6.6/my-project-0.1.0.0/opt/build
  /home/jon/projects/my-project/dist-newstyle/build/x86_64-linux/ghc-9.6.6/my-project-0.1.0.0/opt/build/autogen
  /home/jon/projects/my-project/dist-newstyle/build/x86_64-linux/ghc-9.6.6/my-project-0.1.0.0/opt/build/global-autogen

cabal repl --enable-multi-repl component-b component-c
ghci> :show paths
current working directory: 
  /home/jon/projects/my-project
module import search paths:
  modules/component-b/src
  /home/jon/projects/my-project/dist-newstyle/build/x86_64-linux/ghc-9.6.6/my-project-0.1.0.0/l/component-b/opt/build/component-b
  /home/jon/projects/my-project/dist-newstyle/build/x86_64-linux/ghc-9.6.6/my-project-0.1.0.0/l/component-b/opt/build/component-b/autogen
  /home/jon/projects/my-project/dist-newstyle/build/x86_64-linux/ghc-9.6.6/my-project-0.1.0.0/l/component-b/opt/build/global-autogen

So seems like when using cabal repl --enable-multi-repl :show paths only returns the module search paths for the first component listed, and so ghciwatch can't find targets of the non-first components because it only searches through the first component's search paths. There may be other problems afterwards, but this is the source of the crash I'm pretty sure.

[georgefst]

I'd love to see this! I'm finding multi-component support in GHCID to be broken, with file changes often not picked up. And I'd rather just switch to this project than debug that one.

[9999years]

@georgefst Unless we can find a way to query GHCi for all the search paths, I'm not sure this is fixable. This might need a patch to GHC or Cabal (not sure which one) before it's usable with either ghcid or ghciwatch.

[georgefst]

This might need a patch to GHC or Cabal (not sure which one) before it's usable with either ghcid or ghciwatch.

I haven't looked in to how it works (or why it doesn't for me), but it's been stated here and here that it already works with GHCID.

[9999years]

@georgefst Ahh, good point, I wasn't thinking carefully. I suspect that the reason it works with ghcid is that ghcid takes the naïve approach of waiting for files to change and issuing a :reload when they do. ghciwatch is much more careful and actually tracks which files are loaded and what modules they correspond to, so it needs to know all the search paths. (This enables --repl-no-load support.)