joshmeredith has quit [Read error: Connection reset by peer]
cvlad- has quit [Read error: Connection reset by peer]
joshmeredith has joined #haskell.nix
cvlad- has joined #haskell.nix
lally has quit [Ping timeout: 260 seconds]
lally has joined #haskell.nix
proofofkeags has quit [Ping timeout: 272 seconds]
la-jesystani has quit [Ping timeout: 246 seconds]
la-jesystani has joined #haskell.nix
<tnks>
If I have haskell-nix, is there an attribute path to the `cabal-install` used by the build that should be cached in iohk's Hydra instance?
<tnks>
I tried `haskell-nix.cabal-install`, but that just got me building all of `ghc`, so I that doesn't seem right, because I built this project... so must have used another instance of `cabal-install`... or did it only use `Cabal` for the build?
la-jesystani has quit [Ping timeout: 265 seconds]
fendor_ has quit [Remote host closed the connection]
fendor has joined #haskell.nix
__monty__ has joined #haskell.nix
<dhess>
michaelpj: that updateMaterialization script is awesome, thanks!
<dhess>
slowly working my way through all of our little haskell tools and projects, adding materialization as I go.
<typetetris>
Should there be a wall clock time difference with and without materializations? On a pc of mine, I have the same time for `time nix-shell --run "echo yay"` in a haskell.nix project with and without materializations ..
<__monty__>
I've been considering doing that too. But I don't quite understand the drawbacks.
<__monty__>
typetetris: Materializing means no IFD, right? So if there's not much of that it wouldn't make much of a difference, if there is though you get rid of some forced sequentiality.
<typetetris>
Hmm, experiment seems to suggest, there wasn't much IFD. I had three or four `cabalProject`, `hackage-package` calls, so I would have expected some speed up.
<michaelpj>
I don't know if it'll take you all the way to no IFD, I think there might still be some internal stuff in haskell.nix
<michaelpj>
we tried to get rid of a bunch of it, but there's probably still some
<michaelpj>
e.g. I think for `shellFor` I think the hoogle isn't materialized
<dhess>
yes hoogle isn't materialized
<dhess>
in shellFor
<dhess>
that's the only one left for me :)
<__monty__>
Does materialization help only with initial evaluation time or does it help after the expressions are in the store too?
<__monty__>
I.e., should I expect a speedup at every entry of nix-shell?
<__monty__>
(Or evaluation by lorri in my case.)
<michaelpj>
evaluation isn't cached
<michaelpj>
any builds caused by evaluation will be
<__monty__>
So the network activity caused by checking index-state and the like won't go away? I guess that accounts for most of the slowness I wanted to get rid of.
<michaelpj>
if you pin the sha256 that at least makes the plan a fixed-output derivation, so it won't do all the networky stuff if you haven't invalidated the hash. But it would still have to realize the derivation to get the plan. Materialization avoids even that
<__monty__>
Ok, I guess I'll try both and time it.
<dhess>
michaelpj: ok so to summarize, to get the most performance benefits from materialization, we should set `index-state`, `plan-sha256` and `materialized` in the package's attributes, right?
<michaelpj>
dhess: you don't need *both* `plan-sha256` and `materialized`. `index-state` you need to make it deterministic!
<michaelpj>
note that we'll pull `index-state` out of your `cabal.project` if you put it there, which is a good thing to do anyway
<typetetris>
I'm confused, please help me. If we don't need *both* `plan-sha256` and `materialized`, why bother with `materialized` at all, `plan-sha256` seems much simpler? Is it just, so you can check in the "cache" into your git repository, so first time users also have a fast experience?
<dhess>
yeah I'm confused as well :)
<typetetris>
Or are there different pros and cons , too?
<michaelpj>
`plan-sha256` makes the plan a fixed-output-derivation, which means that we won't rebuild it if the sha doesn't change. This gets you a lot of the benefit. *But* it's still IFD. `materialized` makes it literally just look at the files on disk, so there's no IFD. IMO `materialized` is also easier to update, because we can write a script to overwrite them, whereas updating `plan-sha256` requires modifying some nix
<michaelpj>
expression!
<michaelpj>
it's the difference between `import (fetchurl { .... sha256 = ... })` versus `import ./some-dir`
<dhess>
right
<dhess>
thanks
<__monty__>
Yes, michaelpj++
<typetetris>
michaelpj++
<michaelpj>
we should clarify the docs, evidently :D
<michaelpj>
we've also just changed our approach a bit: in the beginning the idea was to make things "just work" by using lots of IFD, and then people started increasingly complaining about the IFD :D
<michaelpj>
still, it should be more obvious how to progressively phase out the IFD if you want
<michaelpj>
in fact, I think you may get an error if you do that
<michaelpj>
I still desperately want to get around to testing all the doc examples :(
pie_ has quit [Quit: pie_]
pie_ has joined #haskell.nix
acarrico has joined #haskell.nix
acarrico has quit [Ping timeout: 240 seconds]
acarrico has joined #haskell.nix
<__monty__>
Is index-state: not a top-level option I can specify in cabal.project by itself? Or is that a limitation of haskell.nix. I'm finding I have to explicitly specify packages: ./*.cabal
<michaelpj>
__monty__: I don't understan your question. index-state and packages are completely unrelated options in cabal.project?
<__monty__>
That's what I thought. But when I add a cabal.project with just an index-state I get errors about (default.nix).MyPackage not existing.
<__monty__>
Errors about undefined variables go away again when I add packages: ./*.cabal to that cabal.project.
<michaelpj>
sorry, I still don't know what you're doing. Are you talking about errors from cabal? Or from haskell.nix? does it work with cabal?
<__monty__>
Errors from haskell.nix
<michaelpj>
and it works in cabal?
<michaelpj>
works in cabal & not in haskell.nix -> file a bug
<__monty__>
This is the suspicious warning: "Warning: There are no packages or optional-packages in the project"
<__monty__>
Still checking if it works with cabal. Is there a way to specify index-state for packages in shellFor's tools attribute?
<michaelpj>
try just passing `index-state` :) I think extra arguments just get passed through to the underlying `cabal-project` call
<__monty__>
Doesn't seem to be. Docs say any other attributes are passed to mkDerivation.
<michaelpj>
I think it has to be per-tool
<__monty__>
Huh, looks like it does. Didn't know tools could be of the form `tool = { version = "x.y.z"; }`. TIL
proofofkeags has joined #haskell.nix
julm has quit [Ping timeout: 265 seconds]
<dhess>
michaelpj: if the project has an `index-state` attribute, does that speed things up, or does haskell.nix look in the project's cabal file(s) regardless?
julm has joined #haskell.nix
<dhess>
(answering my own question: seems to make no difference.)
<__monty__>
michaelpj: Cabal doesn't like it either. So it's not a haskell.nix bug I guess.
<__monty__>
dhess: It speeds things up in the sense that the build plan won't change when there's a new index-state on hackage.
<__monty__>
But if you just specify the latest index-state there's probably little difference, maybe a single network trip?
acarrico has quit [Ping timeout: 256 seconds]
pjb has joined #haskell.nix
acarrico has joined #haskell.nix
<dhess>
Nice, on our Hydra, with materialization (and checkMaterialization = true), the eval time for a minimal build on an example project went from 720s to 413s :)
<dhess>
still slow, but I'll take the improvements anywhere I can get them.
acarrico has quit [Ping timeout: 240 seconds]
<__monty__>
michaelpj: Mystery solved btw. Since cabal.project options are "additive" there's no way to override/remove default values so as soon as you have a cabal.project you don't get any default values.
<__monty__>
Oh, and the only default value is "packages: ./*.cabal".
<michaelpj>
dhess: note that `checkMaterialization = true` explicitly re-does the work that materialization normally skips so it can check if what you've checked in is right. So it'll be faster than that locally!
acarrico has joined #haskell.nix
<michaelpj>
__monty__: good to know, thanks!
<michaelpj>
this is the only context in which I'm happy to find out that weird behaviour is due to cabal ;)