| 5 Jun 2025 |
samuel | 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 |
samuel | (not complaining, to be clear, just trying to figure out if there are better ways to work with go in nix) | 06:47:52 |
samuel | What do you mean with "regular devShell"? | 06:52:58 |
Diamond (it/she) | what other languages do you not need to also have a vendorHash for? | 06:53:57 |
Diamond (it/she) | i know go, rust and node by default require those | 06:54:20 |
Diamond (it/she) | and that's like a lot | 06:54:25 |
Diamond (it/she) | just a devShells.default = pkgs.mkShell instead of using your package's build env | 06:54:43 |
samuel | I don't use it for haskell, python, c, ... | 06:54:57 |
Diamond (it/she) | 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/she) | for haskell and C you're basically kind of using Nix as a build tool and dependency management system already | 06:55:20 |
samuel | for those you get the dependencies in buildInputs | 06:55:29 |
Diamond (it/she) | same for Python unless you use like Poetry | 06:55:30 |
Diamond (it/she) | you can theoretically package Go modules up as Nix derivations but like why when the language has already good dependency management on its own | 06:56:04 |
Diamond (it/she) | you'd rather just use the good dependency management and put it behind a fixed-output derivation | 06:56:19 |
Diamond (it/she) | at least for now until Nix has something better to deal with it | 06:56:25 |
samuel | That's fine, I'm not against using vendor :) | 06:56:38 |
samuel | does mkShell for go pull the module dependencies in? | 06:57:39 |
Diamond (it/she) | go the tool will do this for you | 06:58:38 |
Diamond (it/she) | (it does in buildGoModule too) | 06:58:53 |
Diamond (it/she) | ((you just need the FDO hash for its output)) | 06:59:02 |
samuel | the problem with buildGoModule is that it sets the flag to do vendoring, if mkShell doesn't do that it might be nicer | 06:59:55 |
samuel | I'll give it a go later today | 07:00:08 |
Diamond (it/she) | i mean it might if you tell it to, but all of your mkShell should just be packages = [ go ] which only grabs the package in | 07:00:31 |
Diamond (it/she) | maybe gopls and gotools for the standard dev tools | 07:00:44 |
Diamond (it/she) | LSP + goimports | 07:00:47 |
Diamond (it/she) | also if you don't mind doing go mod vendor but you do mind checking the whole vendor directory in, you could look at gomod2nix which generates a go.sum-esque file that is Nix-compatible instead | 07:03:09 |
Diamond (it/she) | or use Tailscale's funny narhash tool | 07:03:16 |
Diamond (it/she) | or use Tailscale's funny nardump tool | 07:03:30 |
Diamond (it/she) | https://github.com/tailscale/tailscale/tree/main/cmd/nardump
https://github.com/tailscale/tailscale/blob/main/update-flake.sh | 07:04:10 |
samuel | I think I have some ideas now. Thanks! | 07:08:51 |