angerman changed the topic of #haskell.nix to: - alternative haskell infrastructure for nix; logs at
<proofofkeags> it looks like i need to include my .git directory in order to embed the git hash
<proofofkeags> but how
<hamishmack> If you are using the `haskell-nix.haskellLib.cleanGit` it will hide the `.git` dir.
<hamishmack> Best bet to get the hash might be to use something written in nix to access `.git/HEAD` directly then look up the file it points too and access that directly too.
<hamishmack> Is there a way to reproduce the "hsc2hs is missing" error?
<hamishmack> As for the rebuilds when `stack.yaml` changes, the only thing I know that would cause that is if the directory containing the `stack.yaml` file was also a `hs-source-dir:` (so if the `.cabal` file is in the same dir and had `hs-source-dir: .` in it).
<hamishmack> If that is the case the easiest fix is to use a `src` subdir
mariatsji has joined #haskell.nix
<hamishmack> To get the hash I think this should work `let gitHash = __readFile (./.git + ("/" + __head(__match "ref: \([^\n]*\)\n" (__readFile ./.git/HEAD))))`
o1lo01ol1o has joined #haskell.nix
<hamishmack> Then if you want to add it as a CPP macro use something like 'modules = [{ packages.mypackage.components.library.ghcOptions = "-DGIT_HASH=${gitHash}"; }];`
mariatsji has quit [Ping timeout: 272 seconds]
o1lo01ol1o has quit [Ping timeout: 256 seconds]
jkrmnj has quit [Quit: Connection closed for inactivity]
<proofofkeags> hamishmack that seems fine except for the fact that it would break the ability to build this project without nix or I'd have to reconfigure stack to pass those CPP macros
<proofofkeags> I mostly just want to figure out a way to expose the .git dir to haskell.nix, what is the downside of that?
<hamishmack> Well it might be good to filter just the files in `.git` that are actually needed.
<hamishmack> Does it work if you do not use `cleanGit`?
<proofofkeags> that's fine too
<proofofkeags> it does not
<proofofkeags> i tried using "cleanSourceHaskell"
<proofofkeags> also I can't get a basic nix-shell going from these docs
<hamishmack> If not you might need to add the files to `Extra-Source-Files:` in your cabal file
<proofofkeags> I tried adding that both to package.yaml and stack.yaml
<proofofkeags> neither of them were happy about including .git as an extra source directory
<hamishmack> Did they give an error or did the files just not appear to exist?
<hamishmack> Oh
<hamishmack> Hmm package.yaml packages are not cleaned at the component level (because we can't know what files hpack will choose), since we can't know what files hpack will choose.
<hamishmack> BTW if there is a `.cabal` file haskell.nix will prefer that to the `package.yaml` file and ignore `package.yaml` (this partly so that we don't have issues running the wrong hpack)
<hamishmack> So you will have to run `hpack` manually for changes to package.yaml `Extra-Source-Files:` to work.
<proofofkeags> is this true even when using the "stackProject" expression?
<hamishmack> Yes
<proofofkeags> trying again with the ExtraSourceFiles approach
<proofofkeags> fatal: not a git repository (or any of the parent directories): .git
proofofkeags has quit [Quit: Leaving]
proofofkeags has joined #haskell.nix
<hamishmack> This should help with `cleanGit`
<hamishmack> I am puzzled by why `extra-source-files:` would not work though. Have you tried something like `extra-source-files: .git/**` ?
<proofofkeags> yes
<proofofkeags> the problem seems to be that something in the *haskell* build process hates .git
<hamishmack> Is there an example somewhere I could try?
<proofofkeags> not at the moment
<proofofkeags> but honestly if you have any project at all using the haskell.nix infrastructure I'm nigh certain you could repro in a second
<proofofkeags> since this isn't a haskell.nix problem I don't think
<proofofkeags> I think nix is correctly making the files available, but Cabal is choking on the idea of .git being a file and not an actual repo
<hamishmack> Then maybe you can bypass cabal and just tell haskell.nix about the files with `modules = [{ packages.p.components.library.extraSrcFiles = [ "Setup.hs" ".git/**" ]; }];`
<proofofkeags> you have my attention
<julm> proofofkeags: not sure if that may help, but .git can actually be a file when obtained with git submodule, then if you use clean* functions or a flake.nix, this .git file may no longer redirect to an existing location
<proofofkeags> I'm not sure I understand
<proofofkeags> there isn't any submoduling going on here
<proofofkeags> just one repo
<proofofkeags> also fwiw my nix experience is about 5 hours at this point
<proofofkeags> so while I've *heard* of flakes, I'm not sure what to make of your comment
<julm> ok, then that's not the problem you're facing
<julm> I've told you that because you said: "Cabal is choking on the idea of .git being a file and not an actual repo"
<proofofkeags> I'm interpreting that from the form of the error message
<proofofkeags> " fatal: not a git repository (or any of the parent directories): .git"
<proofofkeags> this disappears when I remove hpack/cabal references to "extra-source-files"
<proofofkeags> is this a bug in cabal you think?
<hamishmack> That might be the error git gives when not all the files it expects are found.
<hamishmack> It looks like the `git-hash` package (I think that is the one you said you were using) runs `git` to get the hash
<hamishmack> If that is the case it might be looking files not listed in "extra-source-files"
<hamishmack> however I would expect `extra-source-files: .git/**` to include them all
<hamishmack> If not it could be a bug in the way haskell.nix interprets cabal wildcards. It is not very smart, but it should err on the side of including stuff. So for both `extra-source-files: .git/**` and `extra-source-files: .git/**/x` haskell.nix should just include all the files in `.git`.
<hamishmack> Perhaps it does not handle the case where the `**` wildcard is at the end.
Graypup_ has quit [Quit: ZNC 1.6.1 -]
Graypup_ has joined #haskell.nix
<proofofkeags> like I said, I think it is most likely an issue fundamentally with how cabal handles files that start with ".git"
<proofofkeags> I'm going to try and reproduce that by running this build *without* haskell.nix and see if it still complains that it can't include those files
o1lo01ol1o has joined #haskell.nix
o1lo01ol1o has quit [Ping timeout: 246 seconds]
<proofofkeags> the plot thickens
<proofofkeags> the error "fatal: not a git repository (or any of the parent directories"
<proofofkeags> seems to be coming from GIT
<proofofkeags> I guess the next natural question is where are TH splices run from?
<proofofkeags> as in what is the PWD in their context
proofofkeags has quit [Ping timeout: 258 seconds]
mariatsji has joined #haskell.nix
mariatsji has quit [Ping timeout: 256 seconds]
mariatsji has joined #haskell.nix
o1lo01ol1o has joined #haskell.nix
o1lo01ol1o has quit [Ping timeout: 240 seconds]
fendor has joined #haskell.nix
__monty__ has joined #haskell.nix
fendor has quit [Remote host closed the connection]
o1lo01ol1o has joined #haskell.nix
<tnks> Is the proper way to override dependencies in Haskell.nix to patch the project's cabal.project file?
mariatsji has quit [*.net *.split]
domenkozar[m] has quit [*.net *.split]
hamishmack has quit [*.net *.split]
chessai has quit [*.net *.split]
feepo has quit [*.net *.split]
carter has quit [*.net *.split]
NinjaTrappeur has quit [*.net *.split]
hamishmack has joined #haskell.nix
chessai has joined #haskell.nix
carter has joined #haskell.nix
feepo has joined #haskell.nix
NinjaTrappeur has joined #haskell.nix
<tnks> Another question... I just realized that I've been cargo-culting packages.ghc.flags.ghci = mkForce true
<tnks> What flag is this enabling? I tried to find it in the GHC manual, but didn't find it yet.
domenkozar[m] has joined #haskell.nix
mariatsji has joined #haskell.nix
<angerman> tnks: it will build ghci support into lib:ghc
<angerman> The whole reinstallable story is non-ideal though.
<tnks> ah... I get it... it's not in the manual... this is a flag for building ghc and ghci as a package?
<angerman> tnks: and yes, unless you have very specific “this is only needed when using nix due to...” reasons, overriding the cabal project or stack yaml is the proper way.
<tnks> angerman: okay, thanks. I think I kind of inferred this, but wanted to check that I wasn't supposed to be hand-crafting a materialization or tweaking one generated for me programmatically.
<tnks> Thanks for pointing that out. It makes sense now.
<angerman> tnks: conceptually haskell.nix just tries to make nix understand your haskell project. Ideally you shouldn’t have to mess with nix.
<angerman> As michaelpj likes to point out: if it builds with cabal/stack, it should build with haskell.nix. If it doesn’t, that’s a bug.
<tnks> angerman: cool... on the #cachix channel, michaelpj was suggesting that there was already a Nix expression for building Haskell Language Server. That's what I'm trying to build right now. I got it working for 8.6.5 and 8.8.4 without much hassle. But having a bump with 8.10.2. Still sorting it out.
<michaelpj> I mean we (my team) build hls with Nix, not that the hls folks do
<michaelpj> amusingly, I am in the process of trying to get it to use 8.10 myself
<michaelpj> I suspect that the hls folks who use cabal maybe don't use 8.10, which is why they haven't noticed there's an issue
<michaelpj> in particular, I think stack doesn't build benchmarks by default which is why it doesn't have the problem I'm observing
<tnks> michaelpj: ah... so you're running into a similar problem to myself? It's not doing the "allow newer" for the diagrams-svg package needed by ghcide.
<michaelpj> tnks: try adding `configureArgs = "--disable-benchmarks"` to your `cabalProject` call
<michaelpj> the issue with diagrams-svg is real, but we don't actually care about the benchmarks
<michaelpj> you could also just do `configureArgs = "--allow-newer"`, but this is a bit less of a sledgehammer
<tnks> ah... well nice... I'm going to see if that helps then.
<tnks> michaelpj: but there's already the "allow-newer" in the cabal.project of ghcide. I thought that would do it.
<michaelpj> tnks: cabal.projects don't compose. You use the one for the thing you're actually building, so you're using *HLS*'s cabal.project, and ghcide's is ignored
<tnks> michaelpj: ah... that makes a ton of sense then.
<tnks> when an index-state is specified by both the cabal.project file, and also haskell.nix, which one wins?
o1lo01ol_ has joined #haskell.nix
<michaelpj> haskell.nix
<michaelpj> generally, settings in Nix take priority over settings in the cabal files
<michaelpj> also, not all cabal.project's set index-state at all, of course
o1lo01ol1o has quit [Ping timeout: 256 seconds]
<tnks> michaelpj: okay, so I tried setting a configureFlag for ghcide, but I think that didn't help much because it's failing on generating the plan. Unless I misunderstood you.
<michaelpj> tnks: I said something slightly different "try adding *configureArgs* = "--disable-benchmarks" to your *cabalProject* call"
o1lo01ol_ has quit [Remote host closed the connection]
o1lo01ol1o has joined #haskell.nix
o1lo01ol1o has quit [Ping timeout: 260 seconds]
<tnks> michaelpj: okay... thanks a lot. that makes more sense... and... I totally have a build for 8.10.2 now too.
<michaelpj> \o/
<tnks> So that's 8.6.5, 8.8.4, and 8.10.2. I think that's good progress.
<michaelpj> it's a bit annoying that the `configureArgs` thing isn't part of the module options or something. It does make sense, but I had to hunt for it too...
<tnks> Now Domen was linking GHCIDE dynamically in his ghcide-nix builds. Evidently there's a performance issue (comment links to Do you think I might have to build HLS dynamically linked too?
<tnks> I haven't really used HLS yet. I just wanted to take a moment to build it properly first. So I haven't run into these kinds of headaches yet.
<michaelpj> tnks: no idea, sorry, but I'd be interested in what you find out!
<tnks> Also, I'm still trying to figure out if I need to do the "data" Shake build of HLS. I'd expect HLS do build out this data at runtime... not sure.
<michaelpj> FWIW the one I built this way does seem to work, so it can't be too broken :D
<angerman> tnks: we’ve seen HIE perf issues with plugins.
<tnks> angerman: okay, so to be safe link dynamically? I mean... I guess I can at least try the statically linked one, and have the dynamically linked one if I actually run into a problem.
<angerman> hamishmack: would know the details.
<angerman> Luite is working on unboxed tuples in the interpreter, which resolves the issue we’ve seen. But it’s non trivial to get right genetically.
<tnks> okay, so from that description, it sounds like it might be yet-another performance issue beyond the split-sections thing I linked above?
graf_blutwurst has joined #haskell.nix
<graf_blutwurst> Hi I was wondering if anyone has a good resource on how to add in haskellPackages from some gitrepo (specifically I'm using niv for pinning)
<graf_blutwurst> I would have assumed it would be haskell-nix.project and somewhere there, but I can't find anything
<__monty__> graf_blutwurst: Add them to cabal.project (or stack.yaml, I guess?).
<graf_blutwurst> __monty__: It's specifically built from a repo because it isn't published yet
<michaelpj> as monty says: how would you solve this problem with cabal? Probably add a `source-repository-package` to your `cabal.project`. Do that - it will work with haskell.nix
<graf_blutwurst> thanks a bunch. I'm still a bit new to haskell in general, so please excuse the occasional non-sensical question
<michaelpj> graf_blutwurst: no worries!
o1lo01ol1o has joined #haskell.nix
<graf_blutwurst> adding source-repository-package doesn't seem to be enough as this causes nix-build to fail because it doesn't have git. so i guess i have to add it as a buildInput somewhere?
<michaelpj> I think you're going to need to be a bit more specific on what you're trying to do and what happens!
<graf_blutwurst> right so I would like to add a haskell dependency by building it from source (namely beam). My default.nix and shell.nix pretty much are as on the documentation (that is besides an added ghcide and vscode). I added the source-repository-packages that i need for this and it looks like cabal new-build can resolve everything correctly (its currently compiling). however running "nix-build -A cardstatus.components" it dies with "Th
<graf_blutwurst> location './cardstatus.cabalpackages:' does not exist."
<michaelpj> can you put your `cabal.project` in a gist or something?
<graf_blutwurst> I think i fixed it "packages: ./cardstatus.cabal" to "packages: ./*.cabal" seems to have done the trick for some reason. huh
<graf_blutwurst> but thanks again!
o1lo01ol1o has quit [Remote host closed the connection]
o1lo01ol1o has joined #haskell.nix
o1lo01ol1o has quit [Ping timeout: 260 seconds]
proofofkeags has joined #haskell.nix
o1lo01ol1o has joined #haskell.nix
mariatsji has quit [Remote host closed the connection]
mariatsji has joined #haskell.nix
mariatsji has quit [Remote host closed the connection]
mariatsji has joined #haskell.nix
o1lo01ol1o has quit [Remote host closed the connection]
graf_blutwurst has quit [Remote host closed the connection]
o1lo01ol1o has joined #haskell.nix
mariatsji has quit [Remote host closed the connection]
mariatsji has joined #haskell.nix
mariatsji has quit [Ping timeout: 272 seconds]
o1lo01ol1o has quit [Ping timeout: 260 seconds]
tchouri has joined #haskell.nix
hekkaidekapus has quit [Ping timeout: 240 seconds]
o1lo01ol1o has joined #haskell.nix
tchouri is now known as hekkaidekapus
<proofofkeags> so attempting to fire up the example nix-shell here: does not actually work.
<proofofkeags> it seems that it is complaining about materialized files
<proofofkeags> Materialized nix used for ghc864-boot-packages-nix.nix is missing. To fix run: /nix/store/4xyan3x2rhnr5xy30fx0xp6vn3fdm762-updateMaterialized
<proofofkeags> ^ that is the exact error
<proofofkeags> when I run the recommended fix...
<proofofkeags> Attempted to write to /nix/store/x7frsjx2vki1pwjmhpmyl96bi5d95qnk-source/materialized/ghc-boot-packages-nix/ghc864 in the Nix store! Put your materialized files somewhere else!
<proofofkeags> perhaps something that jumps out as odd to me is that my stack configuration for this should be using an LTS set that is on 8.6.3, yet here it is talking about using 8.6.4
<proofofkeags> what is the supported set of ghc's
Blackraider has joined #haskell.nix
Blackraider has quit [Remote host closed the connection]
<proofofkeags> ugh what are alternatives to cleanGit
<__monty__> filterSource I think it's called, find it in the nixpkgs manual.
mariatsji has joined #haskell.nix
mariatsji has quit [Ping timeout: 240 seconds]
__monty__ has quit [Quit: leaving]
<proofofkeags> ah, great!
<proofofkeags> I have a working build!
o1lo01ol1o has quit [Remote host closed the connection]
o1lo01ol1o has joined #haskell.nix
o1lo01ol1o has quit [Ping timeout: 258 seconds]
<proofofkeags> welp it definitely doesn't seem to work
<proofofkeags> I would have expected it to try and recompile all the dependencies for arm
<proofofkeags> but it seems to only attempt to recompile my project
<proofofkeags> it doesn't appear that cross compiling works (at least to raspberry pi):
<proofofkeags> it doesn't *look* like I'm doing anything wrong, but I'm still very new to this
proofofkeags has quit [Ping timeout: 256 seconds]