<hamishmack>
Sadly `ghc-options` in `cabal.project` file do not make it into `plan.json`. Adding it to the .cabal or ghcOptions will work though.
codygman has joined #haskell.nix
michaelpj has quit [Ping timeout: 268 seconds]
michaelpj has joined #haskell.nix
pjb has quit [Ping timeout: 272 seconds]
proofofkeags has quit [Ping timeout: 256 seconds]
codygman has quit [Read error: Connection reset by peer]
codygman has joined #haskell.nix
fendor has joined #haskell.nix
__monty__ has joined #haskell.nix
dhess has joined #haskell.nix
<dhess>
Thus far I've only been using haskell.nix with my own Cabal projects, not Stack projects. So when I nix-shell in a haskell.nix Cabal project, using the nice `shellFor` function, I know I can just use the standard `cabal` commands in the shell and it gets the packages from the Nix store, etc.
<dhess>
Is the same true for haskell.nix Stack projects? Can I use `shellFor` and then `stack` just does the right thing?
<michaelpj>
dhess: I'm actually not sure. You probably want to use the stack Nix integration with your shell file so that it doesn't try and get its own GHC... I also don't know if stack will take things from the global package db
<michaelpj>
I have a vague memory that stack does its own thing and doesn't work so nicely, but I haven't tried it recently
<michaelpj>
I'd be interested to know
<angerman>
dhess: to add what michaelpj said: we welcome stack compat, but at $work, people have been switching predominantly to cabal, there are only a very few stack holdouts, and they also don’t use nix much to begin with I think.
<dhess>
angerman: sure, I agree with all that and I think that haskell.nix pretty much obviates most of the reasons to use Stack, except as a solver for build compatibility. I only ask because I'm trying to haskell.nix-ify a third-party project that's meant to be used with Stack.
<dhess>
michaelpj: by "stack Nix integration" I assume you mean Stack's built-in Nix support?
<michaelpj>
dhess: yeah it has something that makes it run in a nix shell and assume it's got a GHC there instead of trying to download it, which is what it normally does
<angerman>
dhess: right if you use haskell.nix with a stack project it will forgo any solving and just use the stackage snapshot and any additionally specified packages.
<dhess>
ok I'll test this in a bit.
acarrico has joined #haskell.nix
fendor has quit [Remote host closed the connection]
fendor has joined #haskell.nix
pie_ has quit [Quit: No Ping reply in 180 seconds.]
pie_ has joined #haskell.nix
pjb has joined #haskell.nix
hekkaidekapus has quit [Ping timeout: 240 seconds]
hekkaidekapus has joined #haskell.nix
codygman has quit [Read error: Connection reset by peer]
codygman has joined #haskell.nix
proofofkeags has joined #haskell.nix
codygman has quit [Read error: Connection reset by peer]
codygman has joined #haskell.nix
codygman has quit [Client Quit]
srk has quit [Ping timeout: 240 seconds]
<mpickering>
Is there a way to get better caching when using haskell.nix and github actions? It seems that `cachix push --watch-store` doesn't work like it does with travis.ci
<mpickering>
__monty__: So fixing the plan-sha256 and sha256 should be enough for caching to work?
<__monty__>
Doubt it. That just makes the derivation fixed-output. Which might help with sandboxing? The only way to speed up evaluation is actually materializing.
<__monty__>
Note that I don't know whether this is your problem. If this change in caching performance is very recent it's likely something else. This is just the most common "How do I speed up haskell.nix," answer.
<mpickering>
I didn't ask anything about speeding it up
<mpickering>
The fact is that the cache is not used at all for things built by haskell.nix
<mpickering>
So I was wondering if my cachix configuration was wrong or whether haskell.nix does something to bypass it
<__monty__>
No, the official haskell.nix cache is also a cachix cache and it just works. (Though for now you do want to add the hydra cache too.)
<michaelpj>
mpickering: there's nothing particularly special going on with caching, so I can't say why your cachix invocation isn't doing what you expect. Perhaps you could give a bit more detail about what you're doing and what isn't happening?
<mpickering>
Haskell packages which are not in the iohk cache are not being being cached between CI runs
<__monty__>
And this used to work fine with GH Actions? Or has it only worked with Travis?
<mpickering>
It worked with travis (months ago)
<michaelpj>
mpickering: you're explicitly passing the substituters to `nix-build`... but not including your own cachix
<michaelpj>
is my guess
<mpickering>
My understanding was that passing the options added to the caches searched, not replaced them
<michaelpj>
I have bad news about how Nix handles options D:
<michaelpj>
they override
<michaelpj>
this has been a pain forever, and is why you have to repeat config from the global config if you want to, say, add substituters in `~/.config/nix/nix.conf`
<domenkozar[m]>
mpickering: I'm just working on better ergonomics so you'll have `push-run` that will run the command and then push all the stuff to cachix
<domenkozar[m]>
oh, this is on GA?
<domenkozar[m]>
mpickering: you don't need --watch-store, cachix will push everything built
<domenkozar[m]>
mpickering: ah, you're overriding the substituters :)