aveltras has quit [Quit: Connection closed for inactivity]
fendor has joined #haskell.nix
srk has quit [Ping timeout: 240 seconds]
hekkaidekapus has quit [Ping timeout: 240 seconds]
__monty__ has joined #haskell.nix
acarrico has joined #haskell.nix
<dhess>
I'm using haskell.nix to build a Haskell package which includes an executable. I create an attriubute called foo-server whose value is haskellPackages.foo.components.exes.foo-server. I think add this to a Docker container by including it in pkgs.dockerTools.buildLayeredImage.contents
<dhess>
that all works great
<dhess>
Now I switch to Nix Flakes and I build the same attribute, Docker container definition, etc.
<dhess>
Now the Docker container closure includes the GHC I used to build foo-server!
<dhess>
Thoughts on why that might happen?
<michaelpj>
dhess: you definitely didn't change anything else?
<michaelpj>
judicious use of `nix why-depends` can help
<dhess>
michaelpj: Well, switching to a Flake requires a lot of changes, so no, I can't say that.
<dhess>
I did also change my haskell.nix pin to e02d5a8ca42d10577a4e78e64e4e8c52afeaacd4
<dhess>
yeah it's possible that I bumped nixpkgs to include that in the process, as well.
<michaelpj>
are you up to date with the latest commit to that file?
<michaelpj>
it looks like the one before it might introduce spurious references
<dhess>
hmm possibly not
<michaelpj>
I bet that's it
<michaelpj>
good digging!
<dhess>
I am not synced with that
<michaelpj>
unfortunately it's a change to stdenv, so you can't really find out without rebuilding the world...
<dhess>
But our nixpkgs pin before the Flake change (and this new GHC dependency in our executable) didn't include that change, either.
<dhess>
in other words, the new -frandom-seed behavior introduced by the commit you referenced there has never been included in our builds.
<dhess>
so I'm not certain it's related at all.
<dhess>
it does seem suspicious though.
<michaelpj>
yeah, but your previous commit might have been from before that hook was introduced at all
<dhess>
yeah... possible
<michaelpj>
it was only added in november
<dhess>
that's true. We've been pretty slow about updating the pins in this repo.
<dhess>
Good point. :) Thanks!
<dhess>
I confess I have *no idea* what that hook is meant to accomplish in the first place :D
fendor_ has joined #haskell.nix
<__monty__>
Does it fix a seed so some random processes become deterministic? To work towards reproducible builds?
<dhess>
yeah but I don't understand why it's doing it the way it does
<michaelpj>
yeah, seems like an odd way of doing it
fendor has quit [Ping timeout: 256 seconds]
<dhess>
it seems... the old way used a path to part of the derivation that built it?
<dhess>
and that is what caused the dependency?
<dhess>
that is *weird*
<dhess>
michaelpj: if nothing else, I've learned today about `nix why-depends`!
<michaelpj>
yeah, it's very useful
<michaelpj>
I hadn't seen that version there where it actually shows you the bit of the file that has the reference before
<michaelpj>
usually you just get the derivation chain and you have to puzzle from there
<michaelpj>
still a lot better than nothing!
<dhess>
thank goodness for that, though, otherwise I'd never have figured this out
<dhess>
assuming that is in fact the issue
<__monty__>
As I read it the self-reference was because the hash of that path wasn't truncated.
<dhess>
right. I guess I'm just surprised that a build-time dependency like that causes a runtime dependency
<dhess>
in nix
<__monty__>
Nix inspects the build result to find references no?
<michaelpj>
yeah it's a bit odd
<michaelpj>
and this is in a CFLAGS environment varible?
<michaelpj>
is your executable some kind of weird wrapper with lots of random variables in it?
<michaelpj>
might be interesting to see if you can actually find where the `random-seed` occurrence is
<dhess>
no, it's just a straight Haskell executable
<michaelpj>
weird
<dhess>
Is haskell.nix able to generate fully static executables on Linux?
<michaelpj>
yeah although it requires some hoop jumping
<michaelpj>
I don't remember exactly
<dhess>
ok so there's not a `staticCabalProject` or anything like that? :)
<michaelpj>
no
<michaelpj>
static linking is non-trivial: you also have to build stuff from nixpkgs that you depend on statically, etc. etc.
<michaelpj>
I think we have options for the haskell side, but you often have to do extra stuff to deal with C libraries that you link against
<dhess>
michaelpj: hah! You were right! Before we switched to Flakes, the nixpkgs pin we were using did *not* include the reproducible-builds.sh build hook.
<dhess>
(tracking this stuff down is so much easier with Flakes! It was trivial to verify with Flakes, but took about 10 minutes of digging around and chasing down niv pins to find the old way.)
<michaelpj>
how did flakes help OOI? surely you just check out your old commit and build it?
<dhess>
`nix flake list-inputs` shows every input's pin, plus its transitive dependencies
<dhess>
we use several overlays and combine them, so it's not always obvious where a particular pin is coming from.
<dhess>
ie our package does not just have a "nixpkgs" pin; it gets the nixpkgs pin from another overlay which might get its nixpkgs pin from another overlay, etc.
<michaelpj>
yikes
<dhess>
hehe
<dhess>
It actually all works really well. With Flakes it's even more straightforward as it kind of encourages this kind of composition of many different inputs.
<michaelpj>
I'd read a case-study blog post about it!
srk has joined #haskell.nix
hekkaidekapus has joined #haskell.nix
proofofkeags has quit [Remote host closed the connection]
<ptival[m]>
feeling stupid for asking, but what mechanism lets me tell a given package to use a local copy of some other package rather than the Hackage version? I've tried `pkg-def-extras`, but that might not be the right tool for this?
<ptival[m]>
oh maybe I can just put a cabal.project and avoid doing this via haskell.nix entirely!
<__monty__>
Exactly.
<__monty__>
If there's a cabal/stack way, it should work is haskell.nix's motto.
<ptival[m]>
hmm yeah, it's a bit awkward because the other project uses `cleanGit`, so I guess I have to put it in my index
<__monty__>
Hmm, cabal.project is usually meant to be checked in though. For local changes I think cabal.project.local is more appropriate. Not that that'll help any with cleanGit though.
<__monty__>
Did you know there's `cleanSourceHaskell` btw?
<ptival[m]>
ah, that might be a convenient alternative here, thanks!