Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

depend on libp2p2 dependencies via go-libp2p, don't depend on them directly #664

Closed
phritz opened this issue Jul 26, 2018 · 3 comments
Closed

Comments

@phritz
Copy link
Contributor

phritz commented Jul 26, 2018

go-filecoin has as number of direct dependencies on parts of libp2p (eg, go-libp2p-peer) and we also depend directly on libp2p. This means that (A) we can have version conflicts where we depend on sub-deps of libp2p that are at a different version than the sub-deps depended on by the version of libp2p that we depend on and (B) we have strictly more direct deps than is necessary. We should just depend on go-libp2p for these things.

I think what needs to happen here is:

  1. for each dependency in common between libp2p and go-filecoin, remove that dependency from go-filecoin's package.json
  2. verify that this works by gx-go rewrite --undo && gx-go rewrite so we can see it picking up the right deps from libp2p
  3. commit that change
  4. update go-filecoin to the newest version of go-libp2p and go-floodsub, which should address reconciling fileccoin/ipfs go-ipld-cbor incompatibility #643 (comment) (cc @dignifiedquire )

This is vaguely related to #599 in that it surfaced in #643.

@dignifiedquire
Copy link
Contributor

I believe #695 fixed this, except for the cbor library missmatch, which will eventually be solved.

@ZenGround0
Copy link
Contributor

Coming back to this we need to start using gx correctly, incorporating gx-go rewrites into build process for this to start working. The need for this has become clear during latest libp2p update attempt.

@phritz
Copy link
Contributor Author

phritz commented Mar 27, 2019

this doesn't feel like a priority to fix, i can't imagine us prioritizing it any time soon unless there is real pain, going to close. feel free to reopen if you disagree.

@phritz phritz closed this as completed Mar 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants