buildGoModule: allow modSha256

[zowoq]

I'm not really happy about proposing this but I think we need some way of reliably dealing with these cases when go mod vendor doesn't work that doesn't require manual intervention.

Allowing the use of the previous implementation as a last resort seems the easiest approach.

cc @kalbasit @marsam @Mic92

[kalbasit]

I don't have strong feelings either way tbh. This is an acceptable change as far as I am concerned.

[Mic92]

cc @c00w

[Mic92]

So this is basically the opposite of #93513

[zowoq]

cc ...

We should see about getting a @NixOS/golang

So this is basically the opposite of #93513

Yeah.

I want to get rid of modSha256 but until runVend or some other alternative works properly we may as well just use what we know works.

[zowoq]

With 20.09 getting closing this will at least buy us another few months to find a reliable solution.

[c00w]

I think this is completely ridiculous.

@zowoq is the entire reason we haven't been able to merge runVend, so him claiming we're in some sort of helpless situation here seems extremely duplicitious.

Additionally, it's generally doable to fix specific issues with the vendor folder (as this code shows), in a fairly straightforward way, so I don't understand what benefit we get by undoing the go vendor work.

[Mic92]

@c00w I am not sure they are aware of you progress. I suggest @zowoq to have another look at your PR.

[Mic92]

I would be actually in favor of having vendoring to work with @c00w solution rather than having to maintain to different module implementation.

[zowoq]

Updated this to use https://github.com/goware/modvendor.

The vendor command is a bit long but it seems to work.

[Mic92]

Can you mention this in doc/languages-frameworks/go.xml?

[Mic92]

What is the difference between this and vend?

[zowoq]

Can you mention this in doc/languages-frameworks/go.xml?

I'll add something to the docs if we decide to go with this PR.

What is the difference between this and vend?

It's a simpler tool. It doesn't wrap go commands, it just copies files.

Downside is that it is a simple tool and we need to tell it to what to copy. Also, if we ever need to add more file types for whatever reason we may end up having to fix hashes because if those new file types exist in current packages they weren't being copied.

I'm not sure if this is better approach than vend or not, if we can get the replace problems fixed it may be better to stick with vend.

[Mic92]

Can you mention this in doc/languages-frameworks/go.xml?

I'll add something to the docs if we decide to go with this PR.

What is the difference between this and vend?

It's a simpler tool. It doesn't wrap go commands, it just copies files.

Downside is that it is a simple tool and we need to tell it to what to copy. Also, if we ever need to add more file types for whatever reason we may end up having to fix hashes because if those new file types exist in current packages they weren't being copied.

I'm not sure if this is better approach than vend or not, if we can get the replace problems fixed it may be better to stick with vend.

Having an explicit list does not sounds like a good idea. However I am concerned that if we ever add any file to the whitelist, we might break hashes. Would it be a bad idea to just add everything?

[zowoq]

Would it be a bad idea to just add everything?

We can add as many file types as we want but anything else would require patching.