| 5 Jun 2025 |
 @s_r:matrix.org | I do nix develop on the package that I'm building, with the working path being the source of that package | 06:43:58 |
 diamond (it/its) | yeah don't do that; just use a regular devShell containing your dependencies | 06:44:24 |
| @s_r:matrix.org | Yeah, but for the actual derivation I don't want to commit the vendor directory. I can obviously gitignore it, but then I need to remember to update the vendorHash before merging.
Nothing of that is unsurmountable in any way, but it feels like a slightly awkward workflow, compared to how I would work in other languages. | 06:47:01 |
| @s_r:matrix.org | (not complaining, to be clear, just trying to figure out if there are better ways to work with go in nix) | 06:47:52 |
| @s_r:matrix.org | What do you mean with "regular devShell"? | 06:52:58 |
| diamond (it/its) | what other languages do you not need to also have a vendorHash for? | 06:53:57 |
| diamond (it/its) | i know go, rust and node by default require those | 06:54:20 |
| diamond (it/its) | and that's like a lot | 06:54:25 |
| diamond (it/its) | just a devShells.default = pkgs.mkShell instead of using your package's build env | 06:54:43 |
| @s_r:matrix.org | I don't use it for haskell, python, c, ... | 06:54:57 |
| diamond (it/its) | because the Go build env in Nix sets some extra env vars that you don't want to use for deevlopment | 06:54:57 |
| diamond (it/its) | for haskell and C you're basically kind of using Nix as a build tool and dependency management system already | 06:55:20 |
| @s_r:matrix.org | for those you get the dependencies in buildInputs | 06:55:29 |
