| 5 Jun 2025 |
 diamond (it/its) | when you're packaging, you won't really be able to avoid the vendorHash unless you actually automate it away | 05:55:51 |
| diamond (it/its) | it's not really because of go mod vendor (if anything, vendor actually frees you from needing to update that hash) | 05:56:11 |
| diamond (it/its) | i asked this on the discourse 6 years ago! https://discourse.nixos.org/t/git-buildgomodule-private-repositories/5167 | 05:56:38 |
| diamond (it/its) | browse to your heart's content; there's no 1 good solution afaict | 05:56:48 |
 Paul Meyer (katexochen) | So the first issue here is that the embedding doesn't work as the path to the var is wrong.
You can check with strings result/bin/az-pim-cli | grep v1.6.1
The following patch fixes it to point to the version var in cmd package:
diff --git a/pkgs/by-name/az/az-pim-cli/package.nix b/pkgs/by-name/az/az-pim-cli/package.nix
index 4ff1e44032e7..b27dda9ffaad 100644
--- a/pkgs/by-name/az/az-pim-cli/package.nix
+++ b/pkgs/by-name/az/az-pim-cli/package.nix
@@ -29,7 +29,7 @@ buildGoModule (finalAttrs: {
ldflags = [
"-s"
"-w"
- "-X=main.version=v${finalAttrs.version}"
+ "-X=github.com/netr0m/az-pim-cli/cmd.version=v${finalAttrs.version}"
];
The other thing is that the embedded values will only be used if there is no debug.BuildInfo available, as stated here: https://github.com/netr0m/az-pim-cli/blob/e4bb4d7617a0561ae2fad3fb00c1e12d1548d5fc/cmd/version.go#L50-L53
And as the doc for that func say, it is will always available when build with module support. So you would need to patch that out for the program to actually print the embedded version.
| 06:02:16 |
 @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 |
| diamond (it/its) | same for Python unless you use like Poetry | 06:55:30 |
| 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 |
