stack integration about ghcid HOT 24 CLOSED

Ah, I'm an idiot, you can already specify the command with --command. Still, it would be convenient to default to stack ghci if stack.yaml exists.

from ghcid.

I am a big fan of stack :). You would need a newish Stack (last 2 days), since commercialhaskell/stack#130 was fixed after the first release.

from ghcid.

Actually, that issue isn't yet closed, so you can't have stack integration yet - but as soon as the issue is fixed I'll integrate it.

from ghcid.

I just did:

$ ghcid --command="stack exec ghci tests/Snippet.hs"

and things worked. That remains insanely difficult to form correctly, but it's how I'm running ghcid against individual programs in a project (that lack their own .cabal stanzas) [This is returning to the discussion in #23 about default actions. I keep thinking that:

$ stack exec ghcid FileName.hs

could work, but my mental model of what's going on appears to be off.

AfC

from ghcid.

stack exec ghcid FileName.hs will run ghcid FileName.hs with the proper package databases, etc, but that's not how you run ghcid on a file.

from ghcid.

But it could be! @mitchellwrosen and @afcowie, I have a set of inputs and I need to transform them into a command line:

• Booleans for each of whether there is a .cabal, stack.yaml or .ghci file in the current directory.
• A list of command line arguments (e.g. ghcid FileName.hs would give FileName.hs).

What command line should I produce? When you say stack exec ghcid FileName.hs runs with the "proper" package databases, does that mean that ghci FileName.hs will then work to load everything up?

from ghcid.

Hmm... yeah, it's a bit confusing... is this how it works currently?

• If .ghci then ghci (only useful if your .ghci loads a module)
• If .cabal then cabal repl
• If stack.yaml then stack ghci

I think stack exec ghcid Foo.hs would work if ghcid could "know" that it was being executed by stack, and not the shell, in which case it should, in turn, spawn ghci Foo.hs. stack exec ghcid Foo.hs might simply be the wrong way to use ghcid+stack, for that reason.

from ghcid.

Yep, you have the current mechanism right. I want to add arguments as well, which will change things (e.g. I might run cabal ghci args if I have args instead of cabal repl). I think ghcid should probably know about stack, but stack shouldn't know about ghcid, so I doubt stack exec ghcid will ever work, but ghcid might call stack exec itself.

from ghcid.

@ndmitchell so as far as I can tell, all cabal exec / stack exec are doing is setting up the GHC_PACKAGE_PATH environment variable so that subsequent ghc / ghci commands work with the local sandbox.

So given ghcid is just a wrapper around running ghc is the reason that my convoluted ghcid --command="cabal exec ghci tests/Snippet.hs" has worked.

@mitchellwrosen the whole point is just to be able to run ghcid against a specific .hs file, rather than relying on having an entire cabal stanza just for quickly testing a fragment.

AfC

from ghcid.

The stack behaviour changed, and keeps changing, so I'll wait until they finish doing things before supporting it natively: commercialhaskell/stack#355

from ghcid.

The "what command line should we run" was tracked at #23, and I've updated that and closed it, so I'll leave this just for the stack integration.

from ghcid.

(forget the comment I just made; I forgot that in other projects I had a .ghci that specified:

:set -ilib:src:tests

and with that stack exec ghcid tests/Experiment.hs is working [again]. I look forward to you getting the feature(s) you need stable in stack and invoking it [more] intelligently)

from ghcid.

I gave it another bash. Unfortunately commercialhaskell/stack#1067 means Stack can't open ghcid in ghci, so it's not really ready for prime time.

from ghcid.

(In the process, I raised 7 separate Stack tickets!)

from ghcid.

I raised a ticket to make Stack and ghcid play nicely on their tracker: commercialhaskell/stack#1608

from ghcid.

@ndmitchell Any other stack issues keeping this open?

from ghcid.

@ChristopherKing42 - not really sure where the Stack bugs are or aren't... To be useful, ghcid really needs a command to run that uses stack and opens up into a prompt. Doing a survey of some of my projects, both with their .ghci file and without:

• Hoogle, works with and without .ghci.
• Shake, a total basket case, "module `main@main:Run' is defined in multiple files"
• Ghcid, loads up the executable, but not the test suite.
• Extra, loads up the executable, but not the test suite.

If I pass --no-load to Ghcid or Extra then it fails because I don't have QuickCheck already installed in my sandbox. I've raised commercialhaskell/stack#1871 to ask for a flag, and then I'd probably do the logic:

• If you have a .stack.yml and .ghci and .stack-work I run stack ghci --no-load.
• If you have a .stack.yml and no .ghci and .stack-work I run stack ghci.

The idea of checking for .stack-work is so that projects that have .stack.yml but who have users who chose to use something else don't get impacted.

from ghcid.

So --test is the magic if the first case. With that, I think it's just a question of implementing those semantics.

from ghcid.

Shake, a total basket case, "module `main@main:Run' is defined in multiple files"

interesting, what command did you run for this?
this loaded fine for me
a git clone + stack init + stack ghci --test --no-load

from ghcid.

Wait, I think I know. This is probably without the --no-load and no targets. That would be this issue commercialhaskell/stack#1606 and is because stack it's not smart enough for your style of reusing Main modules across components 😂
( I did suggest refactoring as the lazy solution 🙈 ) I'll probably give the issue a try sometime

from ghcid.

With --test --no-load Shake works perfectly, so I think I'm now happy enough with it, no real desire to change either Shake or Ghcid.

from ghcid.

@ndmitchell Should the readme be changed then?

from ghcid.

no real desire to change either Shake or Ghcid

To clarify, I have no desire to avoid -main-is in Ghcid, but I do now want to support Stack properly using the techniques and choices above.

@ChristopherKing42 - I'd much rather fix the code first, then update the readme to reflect all of that at once.

from ghcid.

All implemented as described above, and seems to work nicely.

I intend to release a new version of Ghcid incorporating these changes in the next few days, so if anyone wants to try in advance, please do so.

from ghcid.