Could you format your commit messages please?

https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md#submitting-changes

Please see #84826 for a discussion about this kind of change;)

Please see #84826 for a discussion about this kind of change;)

Please see #86282 (comment) for previous mention in the is PR :) I think I also dropped 50% of the comments on that issue because I got excited a few hours ago.

@c00w reading your comment in #84826 I got the impression that you primarily argued about the traits of dependency-management in Go, but the original motivation why buildGoModule is discouraged isn't related to the Go-ecosystem itself. The problem is that we're actually "abusing" the concept of fixed-output derivations here: NixOS/nix#2270

This discussion sounds like it belongs in nix#2270 or #84826. However citing nix#2270 as a justification for getting rid of buildGoModules doesn't seem to track logically. The core message in nix#2270 is that doing complicated downloading isn't reproducible. However with buildGoModule it is (and in fact it's a little more reproducible than normal nix downloads since it's validated across the universe of downloads). Additionally, citing a 2 year old discussion that hasn't seemed to have progressed or been accepted as a plan seems to be moving before concensus has been reached. If we can get #84826 merged, then I'll just nuke buildGoModule everywhere. I expect instead we'll end up in a state where we are still using buildGoModule, but may have an alternate strategy for specifying inputs.

I acknowledge that Go is moving towards the module-based approach, but as long as packages have e.g. a vendor/-directory, I don't see a reason to switch and if we want to, we should rather consider adding at least an alternative implementation for modules first.

So there are two bits - you can have modules enabled or disabled, and you can have a vendor folder (enabled or disabled).

with buildGoPackage, my understanding is that modules are disabled.
with buildGoModule, my understanding is that modules are enabled.

If you have no vendor folder this discussion is irrelevent so well ignore that case.

If you have a vendor folder, then buildGoPackage will use the vendor folder (even if you put other dependencies in your go deps, since vendor always wins). So the deps files are a lie for anything vendored :)

NixOS/nix#2270

If you have a vendor folder, then buildGoModule will also use the vendor folder automatically for builds. Just like deps, it's ignored completely if there is a vendor override. I just played with it, and it looks like we're downloading the modules, then ignoring the results - likely a patch to go send to go for the go mod download command. In fact, there is a maybe an argument that we should use go mod vendor instead of go mod download instead of buildGoModule + skip it if the vendor folder already exists.

https://golang.org/cmd/go/#hdr-Modules_and_vendoring

So the conclusion is that we're still building from the vendor folder in buildGoModule, we're just building in the modern mode, rather than the legacy go mode.

We can also add an option to ignore modSha256 in case we want to build solely from vendor/ for buildGoModule. Than I don't see any reason in this case why we would not want to use buildGoModule.

We can also add an option to ignore modSha256 in case we want to build solely from vendor/ for buildGoModule. Than I don't see any reason in this case why we would not want to use buildGoModule.

I fully agree, this would be a totally reasonable solution. In case it wasn't clear: my concerns are not about Go's module system, but about the way we implemented this.

This discussion sounds like it belongs in nix#2270 or #84826.

I disagree: when we switch to the buildGoModule-approach in its current state, we should discuss about this first.

However citing nix#2270 as a justification for getting rid of buildGoModules doesn't seem to track logically.

It's not about getting rid of it, but about the fact that it's currently rather discouraged because of its current implementation. If we can go-modules without the fixed-output derivation for the download for the majority of packages, I'd be fine with this.