<angerman>
hexagoxel: with materialisation you get away with fewer ifds
fendor_ has joined #haskell.nix
fendor has quit [Ping timeout: 240 seconds]
acarrico has quit [Ping timeout: 240 seconds]
fendor__ has joined #haskell.nix
fendor_ has quit [Ping timeout: 240 seconds]
__monty__ has joined #haskell.nix
acarrico has joined #haskell.nix
<hexagoxel>
yeah I am materializing already
<hexagoxel>
and gc-rooting the materialization
<hexagoxel>
ah, so for stack-package-set based setups, you need to gcroot the package.components.x.env derivation
<hexagoxel>
which I guess is an IFD
<hexagoxel>
(or accessed via one in the actual component build)
hekkaidekapus has quit [Quit: hekkaidekapus]
hekkaidekapus has joined #haskell.nix
<hexagoxel>
I have built the library component, ran the tests. Now I am trying to enter a shell with hsPkgs.shellFor, and for some reason it starts building a series of haskell libraries. I don't have any tools defined, and packages is just a singleton of the local package. So.. why is it building stuff?
acarrico has quit [Ping timeout: 260 seconds]
<__monty__>
Hmm, shellFor doesn't default to installing a local hoogle DB does it?
<hexagoxel>
I have "withHoogle = false;" anyway
<hexagoxel>
oh, it is just building ".config.drv"s, so maybe this is harmless?
<hexagoxel>
but "tools = { cabal = "3.2.0.0"; };" makes it start downloading ghc-8.4.4
<hexagoxel>
which is definitely not harmless
<__monty__>
Hmm, tools basically uses hackage-package iirc. So it's not getting those from your stack snapshot.
<hexagoxel>
what stack snapshot? my pkg-set may or may not involve stackage :p
<__monty__>
You mentioned stack earlier, no?
<hexagoxel>
ah, yes. But that was unrelated, and if it was things would be waaay more confusing
<michaelpj>
the stuff in `tools` is not materialized by default
<hexagoxel>
because without "tools = .." I already get a ghc in my shell, so why would it not use that to compile cabal-install?
<hexagoxel>
assuming that the tool somehow is not cached/materialized whatever
<hexagoxel>
the ghc in this case was ghc-8.8, and it still seemed to start bootstrapping ghc-8.4 when triggered by "tools = { cabal = "3.2.0.0"; };"
<hexagoxel>
I am somewhat inclined to consider "tools" a non-feature. The next question is how to get a cabal-3.2 and a ghcid into scope otherwise. I guess just buildInputs.
<__monty__>
And you add these packages to your shells?
<__monty__>
What does haskell.nix use Agda for?
<hexagoxel>
michaelpj: yeah I like that approach.
<hexagoxel>
although.. do you have to use compiler-nix-name to compile your tools? Would a static compiler not suffice?
<michaelpj>
__monty__: *our* project happens to use Agda, yours probably won't :p
<hexagoxel>
you don't really gain anything by having the cabal-install in your nix-shell be compiled with the ghc in your nix-shell
<michaelpj>
that's true
<michaelpj>
just parsimony, I guess
<michaelpj>
it does matter for haskell-language-server, though
<hexagoxel>
yeah, true, it matters for that
<__monty__>
What does your project use Agda for then?
<michaelpj>
so "use the same GHC for everything" is a safe policy, so we do that
<michaelpj>
__monty__: we have some Agda code! So anyway you want to be able to compile that from the shell, but also we extract Haskell code from it and then build *that* Haskell code
<hexagoxel>
I guess. As long as it is not somehow bootstrapping another ghc-8.4 I'd be fine with that :p
<__monty__>
What does this Agda code do though?! Seeing Agda in use is exciting!
<hexagoxel>
oh neat, the buildPackages.haskell-nix.cabal-install is 3.2.0.0. Plus it is in the cache.
<michaelpj>
depends how picky you are. I like to be deliberate about stuff like updating the version of cabal, I don't want that to happen randomly when updating haskell.nix or something
<michaelpj>
__monty__: it's a formalization of a programming language. We extract a Haskell version of the evaluator and test it against the version written directly in Haskell
<michaelpj>
on randomly generated terms
<michaelpj>
it's quite cool
<__monty__>
That does sound super cool!
<hexagoxel>
michaelpj: ah, right.
fendor has joined #haskell.nix
acarrico has joined #haskell.nix
<hexagoxel>
thanks for all the input, I think I got something that might work. Now I only need to test this on more than one package :)
fendor has quit [Ping timeout: 240 seconds]
fendor has joined #haskell.nix
fendor has quit [Ping timeout: 246 seconds]
fendor has joined #haskell.nix
__monty__ has quit [Quit: leaving]
fendor has quit [Ping timeout: 256 seconds]
hekkaidekapus_ has joined #haskell.nix
hekkaidekapus has quit [Ping timeout: 240 seconds]