angerman changed the topic of #haskell.nix to: - alternative haskell infrastructure for nix; logs at
hekkaidekapus{ is now known as hekkaidekapus
acarrico has joined #haskell.nix
acarrico has quit [Ping timeout: 264 seconds]
acarrico has joined #haskell.nix
Graypup_ has quit [Quit: ZNC 1.6.1 -]
Graypup_ has joined #haskell.nix
<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 = ""; };" 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 = ""; };"
<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.
<michaelpj> personally, I like having the extra control, so while I build the extra dev packages with `haskell.nix`, I do it very explicitly:
<__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 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]
hekkaidekapus_ is now known as hekkaidekapus