angerman changed the topic of #haskell.nix to: - alternative haskell infrastructure for nix; logs at
proofofkeags has joined #haskell.nix
acarrico has quit [Ping timeout: 256 seconds]
acarrico has joined #haskell.nix
_rvl has quit [Quit: ZNC 1.7.5 -]
_rvl has joined #haskell.nix
proofofkeags has quit [Ping timeout: 240 seconds]
_rvl has quit [Quit: ZNC 1.8.1 -]
_rvl has joined #haskell.nix
acarrico has quit [Ping timeout: 240 seconds]
proofofkeags has joined #haskell.nix
proofofkeags has quit [Ping timeout: 265 seconds]
<typetetris> Hi there, what are the support nixpkgs versions? 20.03 or already 20.09 ?
<typetetris> How can I change the ghc version in an ad hoc development environment?
<typetetris> I have both `` and `` as substituters and keys ``, ``. Why is my hello world project, that should be build with ghc8102 still downloading ghc844 ?
<typetetris> Okay, so it will probably the nixpkgs version I am using. Its not the one from haskell.nix.
<michaelpj> probably
<typetetris> The other stuff is as stated in the docs.
<michaelpj> sadly it's pretty hard to get reliable cache hits across many revisions of nixpkgs
<typetetris> michaelpj: Yes. And I don't blame haskell.nix for that :)
<typetetris> For non haskell dependencies, is it necessary for them to be taken out of the nixpkgs used for the haskell.nix tooling?
<michaelpj> uhm. not sure. I think generally mixing nixpkgs is probably risky, especially with libraries, but I don't know of anyone who's tried it, so you could find out for us :p for example, haskell.nix will pull out the native dependencies that cabal specifies from nixpkgs, so you might end up with multiple versions of C libraries being linked if you're not careful
<typetetris> Hmm, yeah with libraries it is probably not a good idea. I will try to build the haskell project and join it "externally" with the other stuff needed for the whole project. So its like mixing static executables and should be unproblematic.
<michaelpj> then probably? I guess that would be like pulling an executable from unstable to mix with a stable nixos system
<michaelpj> might do the job for you
<typetetris> Hmm `nix-shell -A shellFor` builds a lot of libraries like time for a project only depending on `base` (some hello world project). What could be the reason for that? (I am not using default nixpkgs suggested by haskell.nix)
<typetetris> Ah, I guess its compiling cabal.
<michaelpj> yeah, if you're not getting cache hits you'll need to build nix-tools for the evaluation, which will take a while
<michaelpj> also `shellFor` has a hoogle in it by default, which adds some stuff
<typetetris> Yay, have cabal and ghc 8.10.2 now via haskell.nix. Now for haskell-language-server :) There seems to be stuff prepared for that?
<michaelpj> yes, as of recent master you should be able to pull it in with the `tools` argument to `shellFor`
<typetetris> The documentation at `` doesn't mention it for now.
<typetetris> I'll try to find it in the source.
<typetetris> That was easy. Add `"haskell-language-server" = "0.5.1";` to the `tools` set and done.
fendor has joined #haskell.nix
<ptival[m]> oh, you can put it there now?!
<typetetris> Worked for with a master from haskell.nix from today.
<typetetris> Hmm okay, for a bigger project of mine, it fails, as haddock on esqueleto fails ...
<michaelpj> in `cabal.project`
<michaelpj> should do it
<typetetris> I don't know how to do it in cabal.project
<typetetris> ok so `packages esqueleto
<typetetris> documentation: false` should do it?
<michaelpj> that tells cabal.project not to build documentation for esqueleto, which should propagate to haskell.nix
<typetetris> hmm that didn't work
<michaelpj> interesting
<michaelpj> what actually goes wrong?
<typetetris> but `modules=[{ packages.esqueleto.doHaddock = false; }];` did work. But I don't understand, why `modules` is a list.
<typetetris> Also via cabal.project would of course be better.
<michaelpj> you know, I don't know why it's a list either (angerman might). I'm quite surprised that the `cabal.project` thing doesn't get picked up...
<michaelpj> can you file a bug for that?
<angerman> modules is a list, so you can combine muliple modules
<michaelpj> but why would you ever do that?
<michaelpj> rather than just... making one attribute set?
<angerman> to target different configurations/ architectures/ ...
<typetetris> I don't know, wether I have the time to make a minimal example.
<angerman> let me find an example.
<typetetris> angerman, that sounds right
<michaelpj> doesn't `mkIf` handle that?
<typetetris> michaelpj: Maybe its because of my directory structure .. but that sounds weird even to me. (Have `dir/cabal.project` for packages in `dir/a/a.cabal` `dir/b/b.cabal` and have `dir/a/shell.nix` referencing `src = ../.;` to pick up the `cabal.project`. I mean it did find packages `b` so it is picked up somehow).
<angerman> hmm I can't find one off hand. just has a bunch of modules grouped mostly by purpose.
<michaelpj> angerman: just delete all those intermediary braces ;)
<michaelpj> typetetris: maybe it's something with how we setup the packages for the hoogle database...
<typetetris> Yea, doint it via the `cabalProject` function and a `modules` argument is fine by me for now.
fendor has quit [Remote host closed the connection]
fendor has joined #haskell.nix
<typetetris> Strange. I checked for typos multiple times .. so it seems cabal only recognizes the first entry of `allow-newer`. ...
<typetetris> looks like it runs the tests for all local packages ...
<typetetris> so `cabal.project` again?
<typetetris> `run-tests: False` in `cabal.project` didn't help.
pjb has quit [Ping timeout: 260 seconds]
<michaelpj> typetetris: hmm, I'm not sure if we obey `run-tests`, I think we might always run them just based on `tests`
<michaelpj> can you open an issue for that?
<typetetris> Yes of course. But using `nix-build -A package-name.components.exes.exe-name` didn't run the tests. I accidentally did a `nix-build` without any options.
<typetetris> When are the tests expected to be run?
<michaelpj> there are derivations to run tests in `hsPkgs.<package>.checks`; `hsPkgs.<package>.components.tests.<test-component>` just builds the test executable
hekkaidekapus_ is now known as hekkaidekapus
acarrico has joined #haskell.nix
__monty__ has joined #haskell.nix
<pie_> would using ccache make my haskell builds faster?
<pie_> is there something like ccache that i could use?
<__monty__> I think cabal's nix-style builds do all the caching you could.
pjb has joined #haskell.nix
hekkaidekapus_ has joined #haskell.nix
hekkaidekapus has quit [Ping timeout: 240 seconds]
__monty__ has quit [Quit: leaving]
hekkaidekapus_ has quit [Remote host closed the connection]
hekkaidekapus_ has joined #haskell.nix
fendor has quit [Remote host closed the connection]
avn has quit [Read error: Connection reset by peer]