| 13 Dec 2024 |
 trexd | Sorry, let me be a bit more clear. There is a main package hasktorch which users should consume but there are also other packages associated with the repository that are only for development purposes. The devshell that we have in the repository builds all of the packages not just hasktorch. Hasktorch has just been updated on hackage and we want to direct users to consume from there using nixpkgs for convenience. | 16:31:37 |
| trexd | https://github.com/hasktorch/hasktorch Here's the project if you're curious. | 16:31:47 |
| 14 Dec 2024 |
|  @srestegosaurio:tchncs.de joined the room. | 01:20:44 |
| @srestegosaurio:tchncs.de | Hi, I'm starting with haskell and I'm not sure how should I setup my projects on nix. | 01:31:49 |
| @srestegosaurio:tchncs.de | I would like to have as much stuff as possible managed by nix. | 01:32:05 |
| @srestegosaurio:tchncs.de | There seams to be several ways to go about it. I would be gratefull for suggestions. | 01:32:36 |
 thirdofmay18081814goya | anyone got an example of a nix package that builds from source using stack install? | 04:39:50 |
| trexd | I like using the shellFor function outlined in the nixpkgs manual. That combined with direnv and cabal2nix make development pretty easy. Let me know if you have more questions :) | 16:59:45 |
| trexd | https://nixos.org/manual/nixpkgs/stable/#haskell-shellFor | 17:00:01 |
| @srestegosaurio:tchncs.de | Thanks! | 17:00:07 |
 maralorn | In reply to @nrs-status:matrix.org
anyone got an example of a nix package that builds from source using stack install? You mean running stack install in a nix build? I am aware of no such thing. | 20:43:26 |
| thirdofmay18081814goya | oh huh, is it usually stack build? | 20:44:06 |
| maralorn | I am not aware of any solution to run stack within a nix derivation. | 20:46:49 |
| maralorn | Usually even stack projects get built with the normal nix Haskell builder via a .cabal file. | 20:47:21 |
| maralorn | But I am not a stack user so I might be wrong here. | 20:47:46 |
| thirdofmay18081814goya | ah I see, ty! | 20:48:29 |
| maralorn | thirdofmay18081814goya: Maybe for a little bit of context (you might know this, I can’t tell) the main difference between stack and cabal-install (apart from different ux) is dependency resolution. And the normal way to build Haskell packages in nixpkgs does not support the dependency resolution mechanisms from either tool. Instead dependencies get provided "manually" from nixpkgs and the package get’s build directly with the underlying library used by cabal-install and stack, which is "Cabal". | 20:54:25 |
| maralorn | There are projects which try to translate stack.lock or cabal.freeze files to nixpkgs overrides but ymmv. | 20:56:03 |
| maralorn | However that might be the way to get closest to the behaviour of stack build. | 20:56:39 |
| thirdofmay18081814goya | I see! thank you very much for taking the time, didn't know about much of this | 20:57:12 |
| 15 Dec 2024 |
 @megmug:matrix.org | Hey there, i am currently working on a stack-based haskell project using nix and VScode. I have a default.nix file setup to declare the base dependecies, which are stack, GHC and HLS. Using stack inside the nix-shell to build the project works fine. What also works is using the nix-environment-selector extension to make VScode aware of the nix environment. What doesn't work is the HLS though - it always seems to hang no matter what i try, but it does start and it does start to initialize using the correctly identified binaries provided by nix. It just hangs there processing after booting up the IDE, and code completions etc. dont work. Is anyone aware of such an issue existing currently? | 17:30:28 |
| maralorn | Launch the nix shell and run HLS on the commandline. If there is a problem you can see it that way. | 17:32:23 |
| @megmug:matrix.org | For context, the nix expression uses channel nixos-24.11 on commit a0f3e10d94359665dba45b71b4227b0aeb851f8e, and stack is configured to use LTS 22.43 - which leads to GHC 9.6.6 and HLS 2.9.0.0 provided by nix. Also, the stackage LTS uses GHC 9.6.6. Also, stack is set up to use the system GHC identified by PATH, so the one provided by nix | 17:33:02 |
| @megmug:matrix.org | Interesting idea, will try out now. Thank you | 17:33:20 |
| @megmug:matrix.org | Run from the terminal it processes the source code, prints out a few diagnostic warning about the files, for example it found some redundant brackets in my code, and quits. I see no errors. So the problem seems to lie in the interplay between VScode and HLS. | 17:38:25 |
 alexfmpe | How do you know nix environment selector is working if HLS isn't? | 17:39:15 |
| alexfmpe | Try running vscode from the terminal inside the nix-shell | 17:39:44 |
| alexfmpe | That should narrow it down | 17:39:49 |
| alexfmpe | Also, make sure you told the vscode hls extensions to take ghc from PATH rather than manage it itself | 17:40:26 |
| @megmug:matrix.org | Hm, it shows that it is using the default.nix environment on the bottom left corner of the window, and also the Haskell extension is configured to use GHC from PATH indeed. Thanks for the suggestion I will try that now | 17:42:03 |
