o1lo01ol1o has quit [Remote host closed the connection]
jbetz has quit [Ping timeout: 260 seconds]
jbetz has joined #haskell.nix
__monty__ has joined #haskell.nix
siers has quit [Changing host]
siers has joined #haskell.nix
siers is now known as ij
fendor has joined #haskell.nix
Hurttila has joined #haskell.nix
Hurttila has quit [Ping timeout: 240 seconds]
srk has quit [Remote host closed the connection]
srk has joined #haskell.nix
acarrico has joined #haskell.nix
<shapr>
Is there a ghcid equivalent in Nix?
<shapr>
would that be something like lorri?
<__monty__>
That's the closest comparison I can think of.
<shapr>
but it doesn't show instant type error feedback?
<shapr>
hmm
<shapr>
Any other suggestions for fast feedback for type errors, etc?
<shapr>
I use haskell-language-server, I wonder if that covers all the same cases?
<__monty__>
Nix is untyped so that'd be an impressive achievement.
<shapr>
I mean
<shapr>
sorry, I meant: if I want to switch entirely to nix and skip out of cabal and stack as much as possible, is there a ghcid I could use for Haskell purposes?
<shapr>
what would be the best way to do the same sort of thing in the world of nix?
fendor_ has joined #haskell.nix
fendor has quit [Ping timeout: 276 seconds]
<michaelpj>
I wouldn't do that if I were you
<shapr>
what would you suggest?
<shapr>
Sounds like my workplace would like to switch to nix for everyday dev (we're using stack) but one of the requests is a ghcid look-a-like
<__monty__>
Just use your stack projects with haskell.nix. That way you can keep using --file-watch or whatever. Or switch to cabal+haskell.nix and use ghcid.
<michaelpj>
I don't even know what "switch to Nix for everyday dev work" *means*
<michaelpj>
like, just write your own GHC calls by hand inside derivations?
<michaelpj>
or, "build derivations to get feedback on a minute-by-minute basis"
<shapr>
our CI is nix-only, our macbook dev chain is stack-only
<angerman>
nix is useful to provision your environment, it's absolutely terrible to actually use as an interactive build tool. You often simply do not want to throw away any intermediate resutls.
<michaelpj>
what does "our CI is nix-only" mean? note that haskell.nix is not "nix-only" in any real sense - it's cabal-based, really!
<shapr>
michaelpj: yeah, good point
<shapr>
I know we're using haskell.nix
<michaelpj>
what angerman said. the granularity that Nix works at is just not good enough for dev work
<michaelpj>
haskell.nix is unusually granular in that it works at the component level, and even that is IMO unworkable
<michaelpj>
your devs will mutiny pretty fast I bet
<shapr>
I like to think an internal nix cache for packages would help
<shapr>
and yes, nix for setting up the environment, haskell-language-server isn't much used because it's unfamiliar
<angerman>
Here's what I think is the most sensible way to approach it: use nix to provision a development shell (so you get around the issue where everyone has a different configuration of tools), have a Makefile with common targets (build, ...) to ensure everyone invokes the tools (cabal, stack, ...) the same (at this point you should have almost the exact same behaviour across all your organisation while still being able
<angerman>
to use fast tools. For CI just turn that build into nix to have a reproducible build.
<shapr>
angerman: thanks for the advice
<michaelpj>
cabal and HLS inside the haskell.nix shellFor works really well
<shapr>
and would also solve my problem that stack's hoogle breaks often
strikerlulu has quit [Ping timeout: 264 seconds]
strikerlulu has joined #haskell.nix
fendor_ has quit [Read error: Connection reset by peer]