Testing Changes to a Forked Module Dependency (go.mod problems)

[r...@robs.io]

I've been working on something that uses a package that I have imported. 

During the development I wanted to improvement on the package that I use. Since I'm anticipating a pull request I forked the module repo (which contains a `go.mod`) and pull down a local copy.

Obviously I cannot import from my forked copy using my username in the import path so I use the "deprecated" `GOPATH` to put my copy of the forked repo into place so that it resolved for imports properly because GOPATH still works.

Now comes the problem. 

As of 1.13 I am now required to either set the "temporary" `GO111MODULE` or *delete* the `go.mod` in my forked copy to get the thing to even build or test. 

The risk of committing my fork with deleted `go.mod` is now real. 

I do not believe this scenario is an edge case. In fact, it is at the core of the open source development process. I clearly cannot halt my development fully until the pull request is approved. And if it isn't approved I will just have to port my code to use my own fork.

I seriously want to know what are my options at this point? I've spend hours pouring over all the docs, this forum and I see no solutions.  It seems that GOPATH may even go away at some point. If so that would ridiculously complicate this entire process that people have been using for almost a decade now. Please tell me I'm missing something easy. I know it isn't GOPRIVATE because that still requires a repo. It isn't anything with GOPROXY because that just changes which repo it gets pulled from. In fact, if the direction is away from GOPATH I have to wonder what will become of everyone facing the very common use case I presented.

Thanks in advance,

Rob

[burak serdar]

On Wed, Jan 1, 2020 at 10:25 PM <r...@robs.io> wrote:
>
> I've been working on something that uses a package that I have imported.
>
> During the development I wanted to improvement on the package that I use. Since I'm anticipating a pull request I forked the module repo (which contains a `go.mod`) and pull down a local copy.
>
> Obviously I cannot import from my forked copy using my username in the import path so I use the "deprecated" `GOPATH` to put my copy of the forked repo into place so that it resolved for imports properly because GOPATH still works.

If the original package is github.com/X/Y and you forked it to
github.com/A/B, then add a replace directive into your go.mod file
with:

replace github.com/X/Y => github.com/A/B

to point it to your github copy, or if it is local:

replace github.com/X/Y => /path/to/package

This way you can still import the original package while using the forked copy.

>
> Now comes the problem.
>
> As of 1.13 I am now required to either set the "temporary" `GO111MODULE` or *delete* the `go.mod` in my forked copy to get the thing to even build or test.
>
> The risk of committing my fork with deleted `go.mod` is now real.
>
> I do not believe this scenario is an edge case. In fact, it is at the core of the open source development process. I clearly cannot halt my development fully until the pull request is approved. And if it isn't approved I will just have to port my code to use my own fork.
>
> I seriously want to know what are my options at this point? I've spend hours pouring over all the docs, this forum and I see no solutions. It seems that GOPATH may even go away at some point. If so that would ridiculously complicate this entire process that people have been using for almost a decade now. Please tell me I'm missing something easy. I know it isn't GOPRIVATE because that still requires a repo. It isn't anything with GOPROXY because that just changes which repo it gets pulled from. In fact, if the direction is away from GOPATH I have to wonder what will become of everyone facing the very common use case I presented.
>
> Thanks in advance,
>
> Rob
>

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a6004da7-83f2-44b4-96b0-b589c1838896%40googlegroups.com.

[Dan Kortschak]

Though also see https://github.com/golang/go/issues/26640