libp2p reuse

[mjgarton]

libp2p strikes me as an excellent package to have extracted out of ipfs for greater re-use in other projects. (which I believe was the plan!)

However, many other projects want the flexibility of being able to "go get" and of using standard go vendoring support for their dependencies. Do you think of gx here (and therefore a dependency on ipfs also) would put people off from re-using libp2p?

It's certainly made me think before using. I fully understand why you have done it, and I really like gx actually, but for a "core" library like this, I think better adoption would be achieved by working hard to minimise dependencies.

[whyrusleeping]

@mjgarton i've definitely thought about this, and the easy solution is to run gx-go rewrite --undo (replacing all the imports of gx packages with the original github paths) and commit that back up. Doing so would make libp2p go-get able, and would still be able to use as a gx package (gx does the rewriting on its own).

To this end, making the convention for gx packages to be pushed up without their dependencies changed to the gx paths would be a good start.

[whyrusleeping]

The obvious downside here is that if we make go-libp2p 'go getable' then anyone who doesnt use it with the gx vendored deps would be affected by upstream changes in any of the deps.

[ghost]

True, but that's the expected (least surprising) behaviour in the golang world anyway. And people could use standard golang vendoring to achieve fixed versions.

I tried gx-go rewrite --undo and got

ERROR: build of rewrite mapping failed:
 loading dep "go-libp2p-secio" of "go-libp2p": failed to find package: open /home/gartonm/gopath/src/gx/ipfs/QmeBhrdD3K5aMCubZMwhAbcCuHbWjTvVbhQX73kFx2qQfs: no such file or directory

What did I do wrong?

[ghost]

@martingartonft I think you'll have to install once in order for rewrite --undo to work. It seems to require the packages being present locally.

[whyrusleeping]

I should do better with that error message...

[shazow]

FWIW I was going to mess with libp2p today but upon seeing that I'll need to figure out gx I ended up deferring it to another day. Would be nice if gx was an optional bonus rather than a requirement. Some related conversation here: shazow/ssh-chat#140 (comment)

[mjgarton]

I have to say, I've done the same for now (deferring)

gx does seem a really nice tool, but to a newcomer and someone just looking for a nice core p2p library to go-get and use, it's possibly enough to put people off quickly, which is a shame.

Once ipfs is everywhere it will make more sense (and for building ipfs itself it makes sense now)

[whyrusleeping]

@shazow @mjgarton I agree with the point of making gx usage an enhancement as opposed to a requirement.

[whyrusleeping]

ask and you shall receive: #40

[whyrusleeping]

@mjgarton @shazow let me know how using libp2p goes now. Please file issues for any and all weirdness

[mjgarton]

thanks @whyrusleeping I will let you know although i wont have more time to look at this for a couple of weeks or so.

[shazow]

@whyrusleeping Trying it out but there are no real overarching docs or working examples (libp2p-examples is outdated). Any pointers?

[whyrusleeping]

@shazow yeah, i'm working on getting the examples working again. I realized i need to get these merged for it to work again. I'll ping back here once the examples are back to being functional

[daviddias]

Examples are running for me (in my machine™). It should be easier now for everyone to try it out. @shazow @mjgarton wanna try giving it another spin?

[Stebalien]

(I'm pretty sure it's currently broken without gx due to some changes being pushed through the stream muxer libraries)

[pedronasser]

I really like this library. But sincerely I aborted using it in two projects because of the necessity of using gx to pull all required dependencies.
I really like the idea behind gx but is not working very well at least for this project.
Sometimes it fetches all dependencies correctly but most of the time it just breaks everything.

[Stebalien]

Could you submit a bug report describing what you mean by "just breaks everything"? It's supposed to "just work" so that's a bit of a problem 🙁. Note: I do agree that gx has many problems (especially around updating dependencies) but it shouldn't, generally, break things.

If you're running into a situation with conflicting dependencies, try running gx deps dupes to find duplicate dependencies with different versions and gx deps --tree --highlight=$duplicate_package_name to figure out why you have duplicates.

[whyrusleeping]

A small update here just in case readers haven't noticed, but you don't need to use gx to use libp2p at this point. It should be entirely go get'able (unless we're in the middle of an update, but thats expected since its go). Feel free to use your own method of saving all of your exact set of dependencies such as saving everything into your git repo with dep, or venturing forward and figuring out how vgo is supposed to work :)

We will continue to use gx for 'official' dependency sets, and in the future are planning compatibility between gx and vgo, but gx should in no way get in your way while using go-libp2p.