<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 `https://iohk.cachix.org` and `https://hydra.iohk.io` as substituters and keys `iohk.cachix.org-1:DpRUyj7h7V830dp/i6Nti+NEO2/nhblbov/8MW7Rqoo=`, `hydra.iohk.io:f/Ea+s+dFdN+3Y/G+FDgSq+a5NEWhJGzdjvKNGv0/EQ=`. 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 3.2.0.0 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>
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).
<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]