How do we handle the case of when patches should be applied manually/conditionally?

Is it demonstratively worse to have either

%gosetup
%goautopatch
%goprep

or

%goautosetup
%goprep

instead?

How do we handle the case of when patches should be applied manually/conditionally?

That would actually be trivial to handle cleanly

%if <something>
# apply patches 6 87 456 in that order after unpacking source 3
%global source_patches3 6 87 456 
%else
 # only apply patch 666
%global source_patches3 666
%endif

Your patterns would not work because %goprep -a can process several archives sequentially (similar to %forgesetup -a). Anything not based on a declarative syntax quickly drowns in a maze of brittle switches. But, just do not define %source_patches<x> or set it to %{nil}, and you get back to the current situation where patching is separate.

On the other hand intermediary GOPATH creation in %goprep is heavily dependent on the knowledge of what was unpacked where. That’s why splitting it from the unpacking is a terrible idea.

%goprep -e will let you unpack separately, and I’m pretty sure no one will actually use it, because it will only work if you unpack manually exactly as %goprep needs. So it’s less hassle for the packager to do the unpacking in %goprep than figure what %goprep needs. %goprep -e is only there to let people figure by themselves it’s a terrible idea instead of accusing me of being too rigid.

Of course pretty much everything %setup-related in the forge and go macros is just work-arrounding rpm deficiencies that rpm upstream does not see the point in fixing. There is a huge amount of code that could be deprecated if rpm upstream gave up on the original %setup design and provided a %setupng without all the historical documented %setup deficiencies.

And of course the nice thing of using documented rpm variables instead of macro-specific switches, is that any other macro can read the same variables and implement some other smarter form of processing, without requiring argument surgery.

I don't think it's needed really, it would complexify %goprep. We can use %autopatch after %goprep to the same effect.

I second @eclipseo. Autopatch would add complexities in complex situations(would made using goprep impossible). Notably I have on my mind architecture specific patches, which are not possible with autopatch.

go2rpm includes autopatch -p1 in the template since release 1.9.0

https://pagure.io/GoSIG/go2rpm/c/b7ba195ebf85c2b7025a7d27e0623eb87f0be89b?branch=master

It differs from the initial request of this issue, but should be enough IMO.

The recommended approach to automatically apply patches is now

%goprep -A
%autopatch -p1