Modules 'replace' directive

88 views
Skip to first unread message

Stephen Illingworth

unread,
Jun 18, 2024, 4:47:15 AM (12 days ago) Jun 18
to golang-nuts
Hello,

What's the correct way to do the following:

I'm using a third-party Go module which is no longer under development. I've forked the project in order to apply some patches of my own.

I want to use the new version of the module in my project. The following has been added to the go.mod file (not the real URLs)


Is this a good long-term solution or should I rename all imports so they point to the fork and do away with the replace directive?


Assuming I'm using the replace directive for now, when I do this now after cleaning the mod cache:


The output is this, which is surprising:

go: downloading github.com/me/project/v4 v4.7.2
go: downloading github.com/thirdparty/project v1.12.0

It seems to be pulling the latest release of v1 of the original project. Why is it doing this?



Regards
Stephen

Marcin Romaszewicz

unread,
Jun 18, 2024, 2:33:28 PM (12 days ago) Jun 18
to Stephen Illingworth, golang-nuts
One of your dependencies could, in turn, have a dependency on that third party project. Run "go mod graph" to see what imports what and you should be able to track it down.

As for the replace directive, I've always viewed it as a temporary quick fix. In your own code, you can simply replace the module import with a search and replace, but the harder part is in third party dependencies where you don't own the code. You might want to contact those projects and file Issues or send PR's due to their depending on a dead library.

--
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/ac7067f6-d69a-4daf-b09f-3ad2c8ed6569n%40googlegroups.com.

Stephen Illingworth

unread,
Jun 18, 2024, 3:21:17 PM (12 days ago) Jun 18
to golang-nuts
On Tuesday 18 June 2024 at 19:33:28 UTC+1 Marcin Romaszewicz wrote:
One of your dependencies could, in turn, have a dependency on that third party project. Run "go mod graph" to see what imports what and you should be able to track it down.

I thought about that but there's no reference to anything other than the v4 version of the module.

I've created a minimal project that uses v4 of the original package. And that too draws down v1 of the package in addition to v4.

I've also tried with another package without any replace directive and the same thing happens.

Using https://github.com/go-chi/chi as an example. I create a test program using the "as easy as" example in the README.

go mod init <test_url>
go clean --modcache
go mod tidy

Output:

go: finding module for package github.com/go-chi/chi/v5/middleware
go: finding module for package github.com/go-chi/chi/v5
go: downloading github.com/go-chi/chi/v5 v5.0.13
go: downloading github.com/go-chi/chi v1.5.5
go: found github.com/go-chi/chi/v5 in github.com/go-chi/chi/v5 v5.0.13
go: found github.com/go-chi/chi/v5/middleware in github.com/go-chi/chi/v5 v5.0.13


I can't really pretend to understand how modules work, but none-the-less it seems odd to me. Hopefully, someone will be able to explain it.

 
As for the replace directive, I've always viewed it as a temporary quick fix. In your own code, you can simply replace the module import with a search and replace, but the harder part is in third party dependencies where you don't own the code.

Yes. I think I'm leaning towards replacing all the import references in the code. The replace directive is nice but it probably shouldn't be treated as a permanent change.
Reply all
Reply to author
Forward
0 new messages