| 2 Jun 2025 |
kdn | I do suspect something like this, but got no clue how to verify. I'm running this on AMD CPUs and Intel N6005, it also seems tightly related to nix build environment, it builds perfectly fine as a standalone project outside Nix | 17:31:24 |
kdn | I'd be up for any pointers on how to analyze the situation | 17:50:23 |
K900 | perf top? | 17:54:58 |
| 4 Jun 2025 |
| HedgeMage joined the room. | 19:23:35 |
@awwpotato:envs.net | having some trouble in https://github.com/NixOS/nixpkgs/pull/414070, I'm trying to get the version command to work correctly but it's still not despite me adding the ldflags from the goreleaser | 22:05:15 |
| 5 Jun 2025 |
samuel | What workflow do you typically use to develop in a nix shell? I have some minor trouble with the dependencies:
If I just go in a dev shell (i.e. with nix develop) and run go build it will fail because it expects the dependencies in vendor.
- I can run
go mod vendor and then things work.
- Or I can run
runPhase configurePhase and get the vendor directory from nix, that also works.
The other minor issue is that I need to change the vendorHash every time I change a dependency, or I'd get a stale ~vendor~ directory and nix build fails (which took me a while to figure out, because I was doing go mod vendor to develop in my shell.
From this experience, it seems that running the configure phase is a better approach, but it contradicts a bit what me and @jrick discussed a few days ago, from which I understood (perhaps wrongly) that using go tools directly was preferred.
Curious about what other people are doing :)
| 04:46:00 |
Alison Jenkins | Has anyone got a decent solution to build go projects with private dependencies? | 05:03:22 |
diamond (it/its) | how are you making the devShell? if you use it directly via a package, that's gonna happen | 05:55:30 |
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 |
samuel | 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 |
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/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 |
samuel | 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 |
samuel | 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 |