[Buildroot] [PATCH v4 1/2] package/pkg-golang.mk: allow packages to override download GOPROXY

[James Hilliard]

On Wed, Feb 5, 2025 at 11:54 PM Arnout Vandecappelle <arnout at mind.be> wrote:
>
>   Hi Christian,
>
>   Thank you for summarizing the upsides and downsides of GOPROXY=direct!
>
>   I have a few additions though.
>
> On 05/02/2025 22:22, Christian Stewart wrote:
> [snip]
> > Upsides:
> >
> > - No dependency on a third-party proxy service
> > - Ability to build with GOPROXY=direct for those that require it
> > (otherwise Buildroot breaks for them on default)
>
>   Do we actually have examples of packages that break with the default proxy?

AFAIU the default proxy will not break packages due to the fallback.

>
> > - If go.mod says "foo/bar at version v1.0.0" then we can be sure the
> > Git tag v1.0.0 matches the go.sum.
>
>   Additional upside:
>
> - No risk of failures due to GOPROXY setting in user's environment.
>
>   And final upside (but I don't think it's really relevant for Buildroot):
>
> - We detect issues with upstream go.mod.
>
>
> > Downsides:
> >
> > - Slower fetch (git pull instead of proxy.golang.org)
> > - We need to mirror packages if their dependencies go away (most are
> > on GitHub, though)
>
>   It's not actually that simple though. It should rather be:
>
> - If any upstream disappears, they will need to fall back on sources.buildroot.net.
> - If an upstream is already gone when a package is submitted, we need to do
> pre-vendoring patching to fix it, and we don't currently have infrastructure for
> pre-vendoring patching.
> - There is a (small?) chance that it's impossible to find back an upstream that
> corresponds to (is identical to) the original version that disappeared.

Technically you can just use the caching proxy but I really see no reason
to not just use that in the first place since that's what it was designed for.

>
>
>   I'm still on the fence on what the best approach is... What I do think based
> on the discussion is that we should use the same GOPROXY for everything - there
> really should be no reason to do it differently for different packages.

We should use the golang default of GOPROXY=https://proxy.golang.org,direct
here IMO.

>
>   Right now, I'm actually leaning towards removing the GOPROXY=direct - but then
> we should still set it explicitly. We should probably even allow the proxy to be
> configured. We should definitely not rely on whatever the user set in their
> environment.

Yeah, I was explicitly setting the default GOPROXY in this patch:
https://patchwork.ozlabs.org/project/buildroot/patch/20241028161507.186161-1-james.hilliard1@gmail.com/

>
>   The problem with doing it the right way (i.e. keeping GOPROXY=direct) is that
> it adds a lot of work for us:

I disagree that requiring GOPROXY=direct is a more correct approach,
mostly since it's not the default the golang ecosystem uses.

> - when adding a package that has a broken go.mod, we have to fix it;
> - we currently can't even fix it until the fix is merged upstream because we
> don't have the pre-vendoring patchng infrastructure.

Yeah, it's super messy to workaround the GOPROXY=direct brokenness.

>   A lot will depend on how often and why packages break with the default GOPROXY.

They won't ever break AFAIU since there's still a fallback, so I don't think
that's even an issue to worry about.

>
>
>   Regards,
>   Arnout
>
>
> > When requesting that upstream projects fix the build with
> > GOPROXY=direct it helps to mention why in the PR description.
>
>