In a Cabal/Stack cradle, use the direct/default arguments for Setup.hs

[lukel97]

Setup.hs files should (normally) be runnable with a plain GHC installation,. At least with a simple setup that doesn't depend on any external dependencies, it can use the Cabal library that's wired in with GHC, and the cabal cradle/stack cradle could detect the filepath Setup.hs and return [] for the options. This way we would get rid of those bogus "Can't load the module Setup.hs" errors.

[fendor]

Can you realy know that the file you hit, is really the Setup.hs unless tools themselves produce the real output? It is completely valid to have a Setup.hs module, even in a cabal or stack project. What do you do, if there is really a file called Setup.hs and the cradle is not configured correctly? Any magic is somewhat wrong in my opinion.

cabal and stack need to provide the correct interface, options, etc... I am against adding band aids here. If you really need it, you can tweak it at call site, imho.

[ndmitchell]

There's definitely two valid approaches here - treat Setup.hs as special because it really is, or treat it normally and get lots of errors. My personal view is we should do something special, because Setup.hs is so pervasive, and we want to reduce bug reports. But one special approach would be simply to not have Ghcide on the command line try to run Setup.hs files which are adjacent to a .cabal file. Or even just those Setup.hs files which have main = defaultMain. The number of people who actually edit Setup.hs is minuscule.

[lukel97]

Fendor and I realised that this could probably be handled in cabal show-build-info. A couple of extra things I've observed

1. Whilst you can expose a module/have an executable's main-is as Setup.hs, this is a) extremely rare and b) a mistake, as the (albeit antiquated) Cabal specification mandates that each package has a Setup.hs that conforms to a certain command line interface
2. If we do handle this in cabal show-build-info it should have enough information about the setup-depends fields to actually set up a proper environment for it too, by downloading and building any build-time dependencies etc

This will then need all reimplementing in stack though, although as far as I'm aware the long-ish term plan is to also replicate a show-build-info equivalent in stack, and I believe some work was already carried out in the Bristol Hackathon for this.