Utilizing totally different forks of similar dependency – Getting Assist

Hello.

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 A and 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-E.

Notably, lib-A and 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 substitute statements of lib-E to both lib-A or lib-O. This fails, since my important go.mod declares a direct dependency to lib-E which 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 primary go.modthat time to the person repositories forlibAandlibO. This fails since each modules are nonetheless declared as github.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 libA or 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:

If lib-A and lib-O are forks of lib-E, their go.mod information ought to mirror this, in addition to the import paths in A and O, respectively.

If altering the go.mod information and the import paths isn’t an possibility, you’ll be able to attempt utilizing a Go workspace to interchange the import paths regionally. (Tutorial, reference)

Hey @christophberger,

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 go.mod file.

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.