I’m at the moment confronted with an issue that appears to be fairly distinctive. Hopefully somebody will be capable of assist me out.
Basically, I’m attempting to help two totally different tasks
O, each of which have been constructed on prime of
E. There’s a sizeable go library for
E, let’s name it
lib-E, however with a view to help the opposite tasks, they’ve launched their very own libraries, that are direct forks of
lib-O should not have any import paths throughout the code base, and the
go.mod undertaking definition is equivalent throughout all three libraries:
github.com/maintainer/lib-E. I assume that is achieved with a view to minimise upkeep and permit for a simpler plug-and-play strategy with shoppers of the libs.
Possibly you’re already beginning to see my subject now. Let’s assume I’ve two packages in my code base, one in every of them needs to be constructed in opposition to
lib-A, one in opposition to
lib-O. Each packages are equivalent in code, however as their underlaying dependency libs differ, so does the compiled output.
I’ve tried a number of approaches thus far, all with out luck:
Extracting each packages into their very own repositories, together with their very own
go.mod, every containing
lib-O. This fails, since my important
go.moddeclares a direct dependency to
lib-Ewhich is able to override the module replacements.
Holding the code in a single repository, however utilizing named imports in each packages (i.e.
import libA "github.com/maintainer/libE"), then utilizing two substitute directives in the primarygo.mod
that time to the person repositories forlibA
. This fails since each modules are nonetheless declared asgithub.com/maintainer/libE`, so I find yourself with:
module declares its path as: github.com/maintainer/libE however was required as: libA
Because it stands now, I’m beginning to suppose that what I’m attempting to do is not possible in Go, with the one answer being constructing two small binaries (every instantly in opposition to
libO) after which use RPC between these small adapter binaries and my important software.
That’s clearly a number of overhead I’d prefer to keep away from if one way or the other potential. Can anybody consider a greater answer for this downside?
Hello @byte-bandit, welcome to the discussion board.
I’m unsure if I perceive the issue absolutely, however to me, this appears to the foundation of the issue:
lib-O are forks of
go.mod information ought to mirror this, in addition to the import paths in
thanks for getting again to me, actually recognize the enter. Let me be a bit extra clear in my motivations.
Check out https://github.com/ethereum-optimism/op-geth and https://github.com/OffchainLabs/go-ethereum/ – They’re each forks of
github.com/ethereum/go-ethereum (sorry, I can solely put up two hyperlinks). Notice that neither of them adapt their
go.mod , neither their import paths. I can solely assume that is in order that any client could merely use both of them as a drop in alternative for the unique one through the use of a
substitute key phrase in their very own
I’m sustaining an current code base that makes use of
op-geth and now needs to introduce help for Arbitrum by making a module utilizing the
OfficialLabs implementation. Notice how they’re all pointing to
github.com/ethereum/go-ethereum. Whereas solely supporting
op-geth, this wasn’t a problem, because of
substitute. However having to tug in a second dependency that makes use of the identical import paths has thus far confirmed not possible.
I’ve tried varied choices I might consider, like extracting the code into particular person modules, use work areas, use named imports, I can’t even keep in mind what else at this stage.
What I want is a dependable manner of module stage redirects, that isn’t overridden by the primary module. That doesn’t appear to be allowed with go workspaces.
At this stage, I’m not satisfied that is even potential in
go, however it’s probably I’m merely not seeing the plain right here.