Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: allow go.mod.local to contain replace/exclude lines #26640
I saw that there is a way to use local packages instead of online repo, using the replace() features, which is really cool when developping multiple packages at the same time.
I was wondering if there is a way split in different files the require dependencies and the replace one. Something like that
go_replace.mod => define the replace part.
the go_replace.mod will not be pushed on git, and each developer will create it if needed.
What version of Go are you using (
Could you clarify what is the purpose of separating the data into two files? So that developers don't commit temporary replace directives by mistake? I'd imagine that there could be tooling to help with that. For example, a tool to add and undo temporary directives, or having CI fail on unexpected replace directives.
I'm also worried about adding more special Go module files, even if they are in theory not to be committed into git.
We certainly do need to address that use-case somehow, but splitting up the module definitions doesn't seem like an appropriate solution: ideally I don't want individual developers to have to edit the module definition to do that.
changed the title from
cmd/go go.mod file & replace feature
cmd/go: allow go.mod.local to contain replace/exclude lines
Aug 9, 2018
referenced this issue
Aug 13, 2018
I fall into the use case of "building multiple packages concurrently" as well.
I believe that the first option is the best, but I'm interested in reading what direction you guys are learning toward in the interim.
referenced this issue
Sep 6, 2018
I'm not sure that my approach will help others, but in case it does, (taken from go-nuts)
There is a bare bones workaround without local go.mod nor replacements.
Suppose you need to work on module A and module B simultaneously (hopefully you set things up to avoid this, but hey, it's inevitable)
If you only need to edit one package at a time in at least one of A and B, then you don't need
Let B be the module which has only one package to edit, and p the package.
Copy p somewhere in A, rename import path to p using existing go imports/ide,
In terms of commands and tools, it's very simple: no tools, no replacements, no go.mod.local, no replacements which shouldn't be pushed/commited, no workflow restrictions. Simple "cp -r" and use with editor that understands go imports works fine.
Now, thanks to modules, if your edits correspond to releases, it doesn't even matter in what order
Yes, it's still a PITA. For me it's much less painful than thinking about workflows and replacements.
That said, I do think it would be nice to have the go command do for a set of modules, say go build ./...
bcmills> "ideally I don't want individual developers to have to edit the module definition to do that."
Pondering on how to "merge"
I know that knobs breeding is unpopular among core team but consider it, please.