<phillip>
Hey all :) I build my project with pkgs.haskell-nix.project. I would like to use a postInstall phase to wrap my Haskell executable with wrapProgram to make other executables from the nix store available in the PATH, but I'm stuck with figuring out how to trigger it. It is ignored silently.
<__monty__>
phillip: Which postInstall are you setting? `packages..components.exes..postInstall`?
aveltras has joined #haskell.nix
<phillip>
to be honest it was simply a a `postInstall = ''` in the project derivation. I am a little bit confused by the documentation. Where would I set the packages..componentes.exes..postInstall? It doesn't seem to belong in the project derivation.
<michaelpj>
ocharles: latest nixpkgs is best nixpkgs
<michaelpj>
we're doing most testing on 20.09 now, so it's going to be the most reliable
<michaelpj>
phillip: use the `modules` argument. Something like `modules = [ { packages.myPackage.components.exes.myExe.postInstall = ...; } ]`
<ocharles>
Ok, I'll use that. We do have our own nixpkgs pin, but adding the haskell.nix overlays doesn't seem to work - for example Firefox now fails to build
<ocharles>
So I think I'm going to add an overlay to our nixpkgs which uses Haskell.nix "cleanly" (e.g., not our nixpkgs, not our overlays)
<michaelpj>
ocharles: hmm, that sounds bad. could you open an issue for that anyway?
<michaelpj>
FWIW we use our own pin and it's fine, but maybe we're just on an older pin that doesn't have the issue
<ocharles>
I'm not sure it's worth investigating tbh. We have loads of overlays, an old 20.03 (I think?) revision
<michaelpj>
part of the reason it's done with overlays is so you can glue it onto your own nixpkgs!
<ocharles>
I wouldn't say it's worth the investigation tbh
<michaelpj>
oh
<michaelpj>
yeah, I don't care about 20.03 any more tbh :p
pjb has quit [Read error: Connection reset by peer]
<ocharles>
Hmm, that is good, but as it caused Qt to rebuild, I don't think it adds much - seems like some very fundamental packages change
<michaelpj>
frankly I think we should stop building for 20.03 even: if nixpkgs isn't supporting that far back, I don't think we should...
<ocharles>
I would be fine with it just tracking the latest stable release
<ocharles>
This is quite experimental as is!
pjb has joined #haskell.nix
<phillip>
@michaelpj: Sorry, I am still stuck. `project` or `cabalProject` return a `pkgSet`, that already has `modules` applied, correct? Is then the only option to use `mkCabalProjectPkgSet` and construct this by hand? Is there an example somewhere? 😬
<michaelpj>
phillip: it's an argument to `project`
<michaelpj>
have a look around the `haskell.nix` repo
<ptival[m]>
thanks! so looking around, it seems like the current only solution is indeed to unset `exactDeps`?
<aveltras>
is there a way to get haskell.nix to not error with a permission issue when there are files associated with root user in the project directory ? (the directory is gitignored)
<ptival[m]>
aveltras: what function are you using for gathering the source?
<ocharles>
Yea, the helper from overlays/tools.nix
<ocharles>
The problem seems to be it trying to install Cabal, I think
<__monty__>
ocharles: I use it through the `tools` attribute. `tools = { cabal = "3.2.0.0"; };`
<ocharles>
This is cabal-fmt, not cabal
<__monty__>
Just illustrating the use : )
<ocharles>
Sorry, two issues reported above, but I got cabal working
<ocharles>
Ok. I'm using hackage-tool fine for most other things, just stuck on this one
<ocharles>
Ok, cracked it!
<__monty__>
ocharles: Any reason your target requires cabal == 2.5?
<ocharles>
Nope, neither me or michaelpj have a clue :) But I did manage to fix it, added a comment on the issue
<michaelpj>
I never use `hackage-tool`, but that seems pretty weird nonetheless
<michaelpj>
I just use `hackage-package` directly, IMO it's more straightforward
<ocharles>
hackage-tool just calls that and then projects out the exe, so it's not really doing much more - but point taken
<__monty__>
Yeah, extracting the exes is what makes it more comfortable : )
<michaelpj>
I don't like magic :p
<__monty__>
Weird that the cabal.project was the issue, since a lack of one is exactly interpreted as `packages: .`.
<ocharles>
yea, super odd
<ocharles>
I actually didn't think that was going to work
<dhess>
michaelpj: Yes, I do. But I am *just* about to try upstream, as they just merged Python 3.8.7, which was the last missing piece as far as I know.
<dhess>
One second.
<michaelpj>
upstream nixos-unstable, or 20.09?
<dhess>
master
<dhess>
I don't have a 20.09, sorry. My fork (which does work) is based on nixpkgs-unstable
<dhess>
but I think I can probably deprecate that fork now that Python 3.8.7 is merged. Testing that as we speak
<michaelpj>
well, I'm somewhat resigned to having to follow unstable or something if we try to do this
<michaelpj>
it just doesn't look like 20.09 is going to get to a usable state any time soon
<dhess>
my haskell.nix pin is ... 0f7c5afc41ad315824271ef7f7357e3a8da9908a
<dhess>
I was able to build GHC 8.6.5 and GHC 8.8.4 from haskell.nix using the same pins (on x86_64-darwin and x86_64-linux). I haven't tested those yet on Big Sur, but I don't expect there would be any issues.