| 5 Jun 2025 |
 diamond (it/its) | 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/its) | you'd rather just use the good dependency management and put it behind a fixed-output derivation | 06:56:19 |
| diamond (it/its) | at least for now until Nix has something better to deal with it | 06:56:25 |
 @s_r:matrix.org | That's fine, I'm not against using vendor :) | 06:56:38 |
| @s_r:matrix.org | does mkShell for go pull the module dependencies in? | 06:57:39 |
| diamond (it/its) | go the tool will do this for you | 06:58:38 |
| diamond (it/its) | (it does in buildGoModule too) | 06:58:53 |
| diamond (it/its) | ((you just need the FDO hash for its output)) | 06:59:02 |
| @s_r:matrix.org | 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 |
| @s_r:matrix.org | I'll give it a go later today | 07:00:08 |
| diamond (it/its) | 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 |
