| 14 Dec 2024 |
 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 |
| @megmug:matrix.org | Huh, interesting, if i start it from the nix-shell it works depending on if the env-selector extension is active or not. It its active, it doesn't work (same hang as before) and if I start it with the env-selector disabled, it suddenly works. | 17:47:49 |
| @megmug:matrix.org | In any case, it doesn't seem to be nix's fault | 17:48:19 |
| @megmug:matrix.org | alexfmpe: Thanks for helping me diagnose the issue! It really seems to be the nix-environment-selector extension. Even though it loads the environment (it does say so on the bottom left) and even though the Haskell plugin output suggests it found the correct executables in the nix store, it just hangs after "invoking build tool to determine build flags (this may take some time depending on the cache)" without errors, just periodically saying "Live bytes: 0.00MB Heap size: 0.00MB". Something is borked there in a way that is non-obvious to me. But again, running vscode through nix-shell and disabling the extension fixes it. | 18:15:53 |
| @megmug:matrix.org | Does anyone know of another simple way to have that nix-environment load on vscode start? Maybe other plugins with the same functionality? | 18:17:57 |
 @vigress9:matrix.org | direnv | 18:36:10 |
| alexfmpe | I don't currently trust these tools much myself and just relaunch from the shell annoying as it is | 18:38:48 |
| alexfmpe | Have had stale state with direnv a couple times (at the terminal, not even in the editor) until I eventually went in and manually nuked the cache dir | 18:39:35 |
| alexfmpe | Too much yolo nesting IMO | 18:40:24 |
| @megmug:matrix.org | Hm, so direnv seems to be the de facto standard then. It is unfortunate that nix-environment-selector stopped working, because it can be loaded automatically as a plugin without external dependencies which makes working in teams easier | 18:41:37 |
| maralorn | In reply to @alexfmpe:matrix.org
Have had stale state with direnv a couple times (at the terminal, not even in the editor) until I eventually went in and manually nuked the cache dir Well, direnv has a caching layer which purposefully does not watch everything for updates, but "touch .envrc" always resets it for me. | 18:43:23 |
| alexfmpe | I mean, I'd even like to offer a per project preconfigured editor with nix and all.
But I'd think getting the layering right is massive work | 18:43:25 |
| alexfmpe | In reply to @maralorn:maralorn.de
Well, direnv has a caching layer which purposefully does not watch everything for updates, but "touch .envrc" always resets it for me. I mean, it better watch the file I entered the nix shell from and its transitive closure | 18:44:09 |
| maralorn | In reply to @megmug:matrix.org
Hm, so direnv seems to be the de facto standard then. It is unfortunate that nix-environment-selector stopped working, because it can be loaded automatically as a plugin without external dependencies which makes working in teams easier I don't expect that extension to be generally broken. But I also have no experience with it. | 18:44:41 |
| alexfmpe | I don't reload the nix shell that often that the convenience is worth causing stale state on the other team members that never touch nix files | 18:45:11 |
| @megmug:matrix.org | With the nix-envinroment-selector, i think it was pretty close to that. Your colleagues need to 1. install nix 2. open vscode, trust the workspace and let it install recommended plugins. done | 18:45:16 |
