Using a local copy of an external package?

[Paul S. R. Chisholm]

Hypothetical example: Say I'm writing an application that uses "rsc.io/quote" and I discover a bug in that package that breaks my software. I would of course clone the quote repository, add a test that demonstrates the bug, fix the bug, and submit a patch to the maintainer.

After making the fix but before submitting the patch, I'd like to first import my local copy of the quote package to ensure my change prevents the problem in my application. How could I do that?

Back in the GOPATH days, I could presumably have temporarily used a relative import path:

https://pkg.go.dev/cmd/go#hdr-Import_path_syntax

I'm not sure how that would work in a post-GOPATH environment. (That page also talks about programs in a "work space" and not in a "work space." Apparently "work space" is a technical term in this context, but I don't know what it means. "go help gopath" doesn't help. What is and isn't a "work space"?)

Could I clone the quote repository in a vendor/ directory inside my application directory structure? Are vendor/ directories still used in post-GOPATH environments, or are they considered deprecated or obsolete?

Thanks. --PSRC

[Dan Kortschak]

Module replace statements will help you here.


https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive

[Connor Kuehl]

> On Aug 26, 2021, at 5:21 PM, Paul S. R. Chisholm <psrch...@gmail.com> wrote:
>
> Hypothetical example: Say I'm writing an application that uses "rsc.io/quote" and I discover a bug in that package that breaks my software. I would of course clone the quote repository, add a test that demonstrates the bug, fix the bug, and submit a patch to the maintainer.
>
> After making the fix but before submitting the patch, I'd like to first import my local copy of the quote package to ensure my change prevents the problem in my application. How could I do that?

I recently did something like this:

1. Fork the repository
2. Clone it, fix it up
3. Push your changes to your fork
4. Then, in your project:

go mod edit -replace github.com/upstream_org/repo=github.com/your_user/repo@branch

The thing I don’t like about this approach is having to push to the remote each time I want to iterate.

However, after writing this all out, I recently did a quick experiment to see if I could just operate on a local copy and it seems to have worked!

1. Clone the repository
2. Fix it up locally
3. Then, in your project:

go mod edit -replace GitHub.com/upstream_org/repo=/path/to/your/clone/of/the/patched-project

Connor

[Connor Kuehl]

Oops, I see another reply to this thread linked to a document that has a better description of what I stumbled through. :-)

Connor

[Nikhilesh Susarla]

The replace works. But somehow lately I'm facing issue with replace. 
In my go.mod file I wrote replace for the package referring it to local package using ../package name

But when I go do go mod tidy in that package, it brings back that package referring to the github.com in the require. 

I'm not sure what to do.
Even tried the go mod edit -replace command too, but if I do go mod tidy it doesn't create a local reference with 00000.00, instead it refers to the original github.com pkg. 

Thank you

[Manlio Perillo]

On Friday, August 27, 2021 at 12:22:54 AM UTC+2 Paul S. R. Chisholm wrote:

Hypothetical example: Say I'm writing an application that uses "rsc.io/quote" and I discover a bug in that package that breaks my software. I would of course clone the quote repository, add a test that demonstrates the bug, fix the bug, and submit a patch to the maintainer.

After making the fix but before submitting the patch, I'd like to first import my local copy of the quote package to ensure my change prevents the problem in my application. How could I do that?

In Go 1.18 you can use the workspace mode:

https://pkg.go.dev/cmd/go@master#hdr-Workspace_maintenance

https://tip.golang.org/ref/mod#workspaces

https://golang.org/design/45713-workspace

 

> [...]

Manlio 

[Nikhilesh Susarla]

I was trying to init the work file as instructed, but I have a package which still doesn't work in 1.18

So, is there any other alternative?

Thank you

Susarla Nikhilesh

[Manlio Perillo]

Update quic-go to the latest release:
https://github.com/lucas-clemente/quic-go/releases/tag/v0.25.0

Manlio 

[Nikhilesh Susarla]

I updated the project. 

ran go work init cmd

then added 

use ../go-bitswap

replace github.com/ipfs/go-bitswap v0.5.1 => ../go-bitswap`

and comment in my go.mod file. 

But when I run go mod tidy it comes back in the go.mod file. 

using go 1.18v 

workspace : D:\test\workspace

hierarchy : workspace\src\github.com\ipfs\go-bitswap

                  workspace\src\github.com\ipfs\go-ipfs

So, in the go-ipfs folder go.mod file I am trying to refer to the go-bitswap local directory.

Thank you

Susarla Nikhilesh

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/3c3m4anlzR8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f5ee2267-4cbf-4652-8b17-c4f7a47f5badn%40googlegroups.com.

[Manlio Perillo]

The `use` directive must be added in the go.work file, not in the go.mod file.

Also, you can use  `go work use` command, instead of manually editing the go.work file.

Manlio

[Nikhilesh Susarla]

I did place them in go.work file only. 
I commented the package in go.mod file.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f0d86f2d-fe48-4653-91b6-05bf00abc525n%40googlegroups.com.

[Manlio Perillo]

I tried to reproduce the problem and indeed `go mod tidy` seems to ignore the go.work file.

This seems to be a bug; a opened the issue #51106.

Manlio