angerman changed the topic of #haskell.nix to: - alternative haskell infrastructure for nix; logs at
acarrico has joined #haskell.nix
proofofkeags_ has quit [Ping timeout: 240 seconds]
proofofkeags has quit [Ping timeout: 240 seconds]
proofofkeags_ has joined #haskell.nix
proofofkeags has joined #haskell.nix
acarrico has quit [Ping timeout: 244 seconds]
proofofkeags_ has quit [Ping timeout: 256 seconds]
proofofkeags has quit [Ping timeout: 256 seconds]
hekkaidekapus{ has quit [Remote host closed the connection]
hekkaidekapus{ has joined #haskell.nix
fendor has quit [Quit: Leaving]
<ptival[m]> michaelpj: indeed, if I add `set.ghcide.components.exes.ghcide` to `buildInputs`, it builds ghcide perfectly
<ptival[m]> my larger context problem is that haskell-language-server is attempting to rebuild ghcide itself, and fails because the ghcide dependencies aren't around... which is why I attempted to put ghcide in the `packages` field in the first place
<michaelpj> ptival: you shouldn't need to do that, dependencies for source-repository-packages should be there
<michaelpj> oh hm, is that true?
<michaelpj> because cabal is weird about them
<michaelpj> it does try to rebuild them, typically
<michaelpj> maybe haskell.nix just sticks them in the package db and assumes that will be fine, but then cabal ignores it
<michaelpj> could happen
<michaelpj> putting `ghcide` in the `packages` field seems somewhat reasonable, it certainly shouldn't hang
<michaelpj> what exactly are you doing?
<michaelpj> like, what does your `shellFor` call look like?
<ptival[m]> here is my default.nix (and you can find the cabal.project in there too if needed)
<michaelpj> so you add `p.gchide` to the list?
<michaelpj> seems reasonable
<michaelpj> ptival: not sure what's up yet, but I can offer you an alternative approach to getting HLS:
<michaelpj> i.e. just make a `cabalProject` out of it, and then stuff the exectuable in your shell like any other `nativeBuildInput`
<ptival[m]> oh an alternative sounds wonderful, thanks, I'll check it out!
<michaelpj> I tried adding a package which we have as a `source-repository-package` to my shellFor packages and it was fine, so it must be something more specific about ghcide....
<ptival[m]> ah, your alternative worked great, thanks a lot!
<michaelpj> yay
<michaelpj> I would still like to know wtf happened to you with the shellFor...
fendor has joined #haskell.nix
acarrico has joined #haskell.nix
<hexagoxel> btw since 09526c85558417de609ced98460392460b025b98 iohk.cachix does not even seem to contain the ghcs any longer, and you need or you will start compiling ghc with the most basic of haskell.nix setups. Just mentioning in case this is an accident in the setup or to maybe you want to update the docs.
<hexagoxel> (this is _not_ about ghc-8.4, but 8.6/8.8)
<michaelpj> the docs do say that you should use the hydra cache, although people seem to have difficulty reading this :) so we should make it really obvious
<hexagoxel> oh, I see jD91mZM2 mentioned the same above.. should have read the scrollback
<hexagoxel> michaelpj: reading docs? who does that? :D you obviously just copy the suggested commands, and there is just the "install cachix" and the "cachix use iohk" ones :p
<michaelpj> I think also we just need a very loud section in the README that says "The #1 problem people have using haskell.nix is rebuilding more than they should, if this is happening to you please read section X carefully"
<hexagoxel> there is a flag to nix-build to never build locally. Could provide a sanity-checking command to run that tries to fetch just the ghc, and never starts compiling it locally.
<hexagoxel> although it is project-specific which ghc you'd want to download, and you can't phrase it as a nix expression because it must be an argument to nix-build..
<hexagoxel> you can't even evaluate the stackProject expression, because it tries to build ghc-8.8 (I suppose to build stack or stack-nix or some other tools required just by the ifd)
<michaelpj> we have some internal disagreement over whether the nix-tools we use should be built with a fixed GHC, or the one that your project uses. One is easier to get cache hits for, the other reduces the dependency closure...
<michaelpj> well, I tried to make it more obvious:
<hexagoxel> thanks!
fendor has quit [Ping timeout: 265 seconds]
hekkaidekapus{ has quit [Remote host closed the connection]
hekkaidekapus{ has joined #haskell.nix
hekkaidekapus{ has quit [Remote host closed the connection]
hekkaidekapus{ has joined #haskell.nix
<jD91mZM2> michaelpj: You removed the mention of cachix completely? Is it not good to do both?
<jD91mZM2> The main problem is that large code block of cachix, followed by that small code block of hydra cache configuration following after, looking like a secondary optional step. And the title "Setting up the Cachix binary cache" further signifying that Cachix is the significant part.
<jD91mZM2> The "Note" doesn't help either. The promise of "improved chances" doesn't look worth the trouble.
proofofkeags_ has joined #haskell.nix
proofofkeags has joined #haskell.nix
<jD91mZM2> I mean your new changes have solved this, so I'm not sure why I'm bringing this up. Maybe it's a defense mechanism :)
proofofkeags_ has quit [Remote host closed the connection]
proofofkeags has quit [Remote host closed the connection]
proofofkeags has joined #haskell.nix
proofofkeags_ has joined #haskell.nix
fendor has joined #haskell.nix
proofofkeags__ has joined #haskell.nix
proofofkeags_ has quit [Ping timeout: 240 seconds]
proofofkeags has quit [Ping timeout: 240 seconds]
proofofkeags has joined #haskell.nix
fendor_ has joined #haskell.nix
fendor has quit [Ping timeout: 272 seconds]
fendor_ is now known as fendor
<michaelpj> [jD91mZM2]( the cachix one isn't being pushed to at the moment, so it's actively misleading! Even worse, since as you point out, it looks like the "main" thing to do, currently!
__monty__ has joined #haskell.nix
domenkozar[m] has quit [Quit: killed]
ptival[m] has quit [Quit: killed]
Ericson2314 has quit [Quit: killed]
siraben has quit [Quit: killed]
michaelpj has joined #haskell.nix
Ericson2314 has joined #haskell.nix
jonge[m] has joined #haskell.nix
siraben has joined #haskell.nix
ptival[m] has joined #haskell.nix
domenkozar[m] has joined #haskell.nix
hekkaidekapus} has joined #haskell.nix
hekkaidekapus{ has quit [Ping timeout: 240 seconds]
hhefesto has joined #haskell.nix
<hhefesto> Kind haskell.nix gurus <3. How does one go about overriding a haskell package in a `haskell-nix.cabalProject`?
<hhefesto> I have a default.nix that correctly builds the package I want (`derive-storable-plugin`)
<hhefesto> And, with help from here, I've already been able to do an overlay on nixpkgs
<hhefesto> but I couldn't find how to do it for a haskell package
hekkaidekapus} is now known as hekkaidekapus
<hhefesto> I would have thought something like `pkg-def-extras = with pkgs.haskell.lib; [(h: {derive-storable-plugin = import ../derive-storable-plugin/default.nix;})];` would work, but it doesnt
<hhefesto> as in `pkgs.haskell-nix.cabalProject.pkg-def-extras`
<__monty__> hhefesto: You'll probably want to look into how to do it from cabal.project, haskell.nix philosophy is the build tools' workflow should just work.
<__monty__> More activity during utc working hours usually, btw.
<hhefesto> ohh
<hhefesto> thanks!
<__monty__> Don't thank me yet. I might've just started you down a rabbit hole on a wild goose chase : ) Good luck, though!
__monty__ has quit [Quit: leaving]