Nix + Go | 235 Members | |
| Go packaging for and with Nixpkgs. | Be excellent to each other. | 48 Servers |
| Sender | Message | Time |
|---|---|---|
| 17 Dec 2024 | ||
| not sure what I did but it started working. Some random stuff i had done was adding attic and substituters, and now I recently added myself as trusted user | 12:30:45 | |
| 20 Dec 2024 | ||
| 13:03:09 | ||
| 21 Dec 2024 | ||
| Hey all, I recently got annoyed by the lack of caching in incremental Go builds in Nix and decided to just fix it to work the way I thought it should (opt-in similar to ccache). I came up with this: https://github.com/dnr/nix-gocacheprog Let me know how it works for you! | 16:06:16 | |
In reply to @dnrix:matrix.orgNice! We are working on a similar approach with gocacheprog! https://github.com/adisbladis/gobuild.nix/ | 16:10:41 | |
| Ah, you already saw it. ^^ | 16:11:41 | |
| 22 Dec 2024 | ||
| I did.. that's a more ambitious project and a different focus. If I understand correctly, you end up with one derivation per module and the build caching is effectively at module granularity? I wanted to speed up incremental builds/tests so I wanted file-level granularity, more like ccache. Of course it's at the cost of purity, so it's only useful for development, but for that purpose it should be faster. | 00:54:53 | |
| * I did.. that's a more ambitious project and a different focus. If I understand correctly, you end up with one derivation per module and the build caching is effectively at module granularity? I wanted to speed up incremental builds/tests so I wanted package-level granularity, more like ccache. Of course it's at the cost of purity, so it's only useful for development, but for that purpose it should be faster. | 00:58:28 | |
| I think it's really two projects rolled up into one, with different goals:
| 04:29:21 | |
| I think per module granularity is probably a sweet spot, but you could go finer grained if you wanted to. | 04:29:57 | |
| That's true, per-module is probably fine for most projects. Per-package (or cache object) came out naturally from the way I shared the cache. | 11:10:45 | |
| How do you plan to coordinate writes to a shared impure cache? That's what led me to the client/server model. | 11:11:22 | |
| * That's true, per-module is probably fine for most projects. Per-package (or cache object) came out naturally from the way I shared the cache. And I was specifically trying to speed up the edit/build/debug cycle so any tiny improvement is good. | 11:13:06 | |
| 23 Dec 2024 | ||
| When I'm saying "impure" I'm talking about development shells (and being able to read cache from the store while writing to an impure location), and for that use case there is no coordination problem as there is only a single uid writing to the cache. | 01:53:10 | |
| 26 Dec 2024 | ||
| 20:16:25 | ||
| 27 Dec 2024 | ||
| 12:39:14 | ||
| 15:23:14 | ||
| 31 Dec 2024 | ||
| 21:49:20 | ||
| 1 Jan 2025 | ||
| 14:26:32 | ||
| 18:20:17 | ||
| 5 Jan 2025 | ||
| 07:12:39 | ||
| 6 Jan 2025 | ||
| 12:31:55 | ||
| 8 Jan 2025 | ||
| 14:37:04 | ||
| I don't know if this is the right channel for this question, but seeing as how I'm trying to build a Go application with devenv I figure it would be worth a shot. I have a project that I'm using devenv to manage the development environment, and I have everyithng setup already so I can build the project with What I do know from trial and error:
If it helps here is my default.nix file: | 15:34:39 | |
| 9 Jan 2025 | ||
In reply to@vendion:matrix.orginstallPhase should already both build and move the binary into $out/bin, so you shouldn't be overriding it like that in buildGoApplication | 00:46:45 | |
the only case where that wouldn't be true is if you don't have a package main, but it should complain I think | 00:47:13 | |
what's the output of tree $out after building everything without overriding any phase? | 00:47:25 | |
| also I think you're trying to modify the source directory to add the build output? you can't do that | 00:48:02 | |
$src is immutable | 00:48:16 | |
$src is immutable (practically it's an immutable snapshot of the source code at the point of building) | 00:48:36 | |
In reply to @diamondburned:matrix.orgYeah, that is exactly what I was trying to do. Okay I'll have to rethink my approach as I was wanting to be able to use a CI pipeline to build the artifacts and use them as downloadable releases. The end users are not using Nix so having to work out deployment strategy | 00:51:12 | |