`go-merkledag` dependency version discrepancy with `go-ipfs`

[schomatis]

The go-merkledag gx-version used here,

go-unixfs/package.json

Lines 34 to 37 in f425628

	"author": "why",
	"hash": "QmfGzdovkTAhGni3Wfg2fTEtNxhpwWSyAJWW2cC1pWM9TS",
	"name": "go-merkledag",
	"version": "1.0.1"

differs from the one in go-ipfs, which is causing build problems when using gx-go link to work on this repo through the go-ipfs one.

This also raises the more general question: every time a package dependency shared between the two repos is updated, should it be immediately updated in the other one to avoid breaking the build?

(edit: well, not immediately, but I mean, is there an alternative to doing a local gx update just so gx link can work? given that this extracted repo is meant to be used primarily with go-ipfs, the gx link scenario seems pretty common.)

[schomatis]

/cc @whyrusleeping

[whyrusleeping]

@schomatis Yeah... this is a problem we want to solve with gx. Ideally gx-go link here just works...

cc @Stebalien @travisperson

[Stebalien]

gx-go link should probably:

1. Build a rewrite map using the package.json file in the linked repo.
2. Overwrite this mapping using the package.json in the current repo.

However, modifying a shared dep in that way feels like a bad idea... Is there any way to use the vendor/ directory for this?

---

However, it may be better to finish the next iteration of gx first and then revisit this issue.

[schomatis]

gx-go link should probably:

Build a rewrite map using the package.json file in the linked repo.
Overwrite this mapping using the package.json in the current repo.

@Stebalien Could you elaborate a bit more on this idea please? Even if you consider it sub-optimal it could help me as a temporary solution, this is starting to look like a blocking issue to me when developing across different repos.

[whyrusleeping]

@schomatis in the short term, you can do the gx-go link, and then in the linked package 'downgrade' the changed dep with gx update. That should do the trick (make sure to not commit the deps change).

Mid-term, we should figure out what is preventing go-ipfs from building with unwritten deps, I know there were a couple issues last time I tried.

[kevina]

@schomatis the original issue "go-merkledag dependency version discrepancy with go-ipfs" should fix it self soon once #7 gets merged and bubbled up.

[kevina]

@schomatis this is already fixed, both go-unixfs and go-ipfs use QmXkZeJmx4c3ddjw81DQMUpM1e5LjAack5idzZYWUb2qAJ version 1.0.6 of go-merkledag.

[schomatis]

Hey @kevina, thanks for the ping, forgot to close this issue, this has already been fixed in ipfs/kubo#5336.

(The larger issue of how are shared dependencies that cross API boundaries managed remains unsolved, but I should discuss that elsewhere.)

[schomatis]

@schomatis in the short term, you can do the gx-go link, and then in the linked package 'downgrade' the changed dep with gx update. That should do the trick (make sure to not commit the deps change).

From some recent experiences, sometimes it's not obvious what dependency should be updated and where (without breaking other dependencies).

I think that some of the gx-workspace logic could be leveraged to perform a similar function with gx-go link, that is, to sync all the shared dependencies while working on a linked repository. @Stebalien Was that what you had in mind when you suggested #4 (comment)? Could you elaborate a bit on that please?