Home

blog @main - refs - log -
-
https://git.jolheiser.com/blog.git
My nonexistent blog
tree log patch
chore: clean up gomodsri Signed-off-by: jolheiser <john.olheiser@gmail.com>
Signature
-----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEgqEQpE3xoo1QwJO/uFOtpdp7v3oFAmaNqu8ACgkQuFOtpdp7 v3rqVhAAjP6kbYzeDyhB1alH4T7cpEWanzKnOZZ7oqw5/OBOMBFZk2qhOn9bQPrb G2rsENfHs/VaQLBssonzANVn9VSHX+TCvCnw40D4vR4AUBxsTTCsWwbcKDlmyJdr jGTtZ3sCGLmd5+oIQoe7k7WJa9nzvZj6GyHUUjioMJVrw4od0Ab4QenCOw7FfGJt PxUJX10x5v1k+mhPoPHVOh8PIMYPVYmzcP6moJBebUrDCm9kWQpMftix0vPJVRUm 9//5W8TxqLrjXPNcL9a5od5l1ENJYGNPv7IMynKB3CXT1ttyQ9VpOXxQugAp60bh gxq9rvDWtuRBBNYcTrsI+tRGQ7qQ4UVK7XrcIYi1lZJGYrHzFgg7U33W3vSKuqaA JCXK1gBBI+saCfC2zF53dmha9bfzUDutVFebC6yh2lU49w84VdeWFm1/SW6kLhCB rTjxpDdsPnTyWtzTX3cls8K48NgwmXo977sjxGLA6WivwBdMFQ+VX4IcctAcAtXC 3s6HJNOAv/22J2+iMMHnE4OPJ/69rgzCw7Mv4VCc/zhX8SGE1DureLDB7phQFrI1 GHbpx1xMBKdLZi8FPmoqUCMWjJOjLJIUWM97Aqnn4EMkgG4/OBTJ90mflduXhf2h Ezk94qKhXzPhsztUZRBTF0aJpgJD3J+w57q1T+AeEPlIKFv3PXs= =R2lv -----END PGP SIGNATURE-----
jolheiser <john.olheiser@gmail.com>
2 months ago
1 changed files, 4 additions(+), 4 deletions(-)
M articles/gomodsri.md -> articles/gomodsri.md
diff --git a/articles/gomodsri.md b/articles/gomodsri.md
index 874822d1a164001ef303151ecfa1520bf088f765..5fbd4c28fc84c6c70917bf0e3479f9dfd362fb89 100644
--- a/articles/gomodsri.md
+++ b/articles/gomodsri.md
@@ -7,15 +7,15 @@ +++
 
 ### The problem
 
-When building a Go module with `nix`, generally you would use `buildGoModule`. One thing it shares with other builders in the nix ecosystem is a `vendorHash` property (or similar name).
+When building a Go module with `nix`, generally you would use `buildGoModule`. Like other builders in the nix ecosystem, it uses a `vendorHash` property (or similar name).
 
-Although there _have_ been various workarounds, there's usually no getting around some variation of building, noting the "expected" new hash, and replacing the old hash with the correct one before building works for real.
+Although there _have_ been various workarounds, the process typically involves building, noting the "expected" new hash, and replacing the old hash with the correct one before the build succeeds.
 
 ### The solution
 
-Now, I am admittedly borrowing this idea from [tailscale](https://tailscale.com). I simply wrapped it in a (nu)shell command for easier generic usage.
+My solution is inspired by [tailscale](https://tailscale.com), which I've adapted into a (nu)shell command for easier generic usage.
 
-The original idea combines the [nardump](https://github.com/tailscale/tailscale/tree/ad33e47270509345469af795aed65177df88904e/cmd/nardump) command with the [vendoring](https://pkg.go.dev/cmd/go#hdr-Make_vendored_copy_of_dependencies) ability of Go modules to predict the `vendorHash`. Put together, it can look something like the following:
+The original idea starts with the [nardump](https://github.com/tailscale/tailscale/tree/ad33e47270509345469af795aed65177df88904e/cmd/nardump) command. This is combined with the [vendoring](https://pkg.go.dev/cmd/go#hdr-Make_vendored_copy_of_dependencies) ability of Go modules to predict the `vendorHash`. Put together, it can look something like the following:
 
 - [update-flake.sh](https://github.com/tailscale/tailscale/blob/ad33e47270509345469af795aed65177df88904e/update-flake.sh#L9-L10)
 ```sh