Make `buildGoModule` "failsafe"

I am currently trying to transition the exercism derivation to use buildGoModule rather than the previous buildGoPackage.

So I used a dummy entry for modSha256 as described in How to create modSha256 for buildGoModule. and replaced it with the actual value after first build.

Then I retried and build went through successfully.

Just to be sure everything works, I did a nix-store --gc and built again using the changed derivation.

It failed, because some of the deps seems to have changed and therefore the modSha256 changed.

How can I properly pin it?

As I have messed up my branches and need to recover from that before pushing, here my actual changes to the derivation for playing around:

diff --git a/pkgs/applications/misc/exercism/default.nix b/pkgs/applications/misc/exercism/default.nix
index 590e4cdc4cb..382713d19a9 100644
--- a/pkgs/applications/misc/exercism/default.nix
+++ b/pkgs/applications/misc/exercism/default.nix
@@ -1,11 +1,9 @@
-{ stdenv, buildGoPackage, fetchFromGitHub }:
+{ stdenv, buildGoModule, fetchFromGitHub }:

-buildGoPackage rec {
+buildGoModule rec {
   pname = "exercism";
   version = "3.0.12";

-  goPackagePath = "github.com/exercism/cli";
-
   src = fetchFromGitHub {
     owner  = "exercism";
     repo   = "cli";
@@ -13,7 +11,7 @@ buildGoPackage rec {
     sha256 = "1xvxcl7j5izx5lgmjd97zd28lg2sydwgbgn2cnisz5r0d27pj3ra";
   };

-  goDeps = ./deps.nix;
+  modSha256 = "1p4xjm2zb2xc1qpprj5wlcc9pangbxpx16hx3nbr2caa5gdll5y8";

   meta = with stdenv.lib; {
    inherit (src.meta) homepage;

The modSha256 from the subsequent run was 1d31yrwcyrz0s0155qac76bvf5djqdq9yhdfb5xpvka72ran73dj

I though the go.sum in the repository where pinning (transitive) dependencies on a certain commit, or is it ignored by the buildGoModule?

How are other derivations deal with this? I did a git grep buildGoModule and checked the derivation of some of the results, but I wasn’t able to find anything that would be different to my approach…

I hit this problem yesterday also. I think PR #71049 is trying to fix this.

1 Like

In other words, I have to wait until that one got merged, or is it safe to branch off of that PR, mentioning in my PR that it should not get merged before #71049?

What is the process in such cases?