Workflow for hacking on go-ipfs dependencies?

Help Coding
1

Hi,

I’ve added some features to go-multiaddr (and go-mutliaddr-net) and would like to test my changes with go-ipfs (ipfs executable). However, I can’t seem to figure out a good way of making go-ipfs point to my local git repositories rather than to their ipfs hash. I’ve tried using sed to replace all occurences of gx/ipfs/<go-multiaddr-hash> with github.com/multiformats but this results in the following kinds of errors:

exchange/bitswap/network/ipfs_impl.go:36:38: cannot use (*netNotifiee)(&bitswapNetwork) (type *netNotifiee) as type net.Notifiee in argument to host.Network().Notify:
	*netNotifiee does not implement net.Notifiee (wrong type for Listen method)
		have Listen(net.Network, "github.com/multiformats/go-multiaddr".Multiaddr)
		want Listen(net.Network, "gx/ipfs/QmWWQ2Txc2c6tqjsBpzg5Ar652cHPGNsQQp2SejkNmkUMb/go-multiaddr".Multiaddr)

Does this mean I’ll have to recursively replace the hash in all dependencies, and if so, how? Surely there must be a better way. What workflows do the ipfs developers use? I hope it is not required to upload modified dependencies to ipfs in order to use them locally.

1 Like
2

So, we use a tool called gx to manage our dependencies. In this case, you want to use the gx-go link command.

cd $GOPATH/src/github.com/ipfs/go-ipfs

# install gx (if you don't have it)
go get github.com/whyrusleeping/gx
go get github.com/whyrusleeping/gx-go

# install the deps (if you don't yet have them)
gx install

# Find the current version of go-multiaddr being used
gx deps -r  | grep go-multiaddr

# Replace the multiaddr dep
# NOTE: This will modify your source code in github.com/multiformats/go-multiaddr. It'll replace the github.com/... paths with gx/... paths.
gx-go link $HASH

You can undo the link by running:

gx-go link -r -a # remove all linked deps

You can undo the modifications to the go-multiaddr library by running:

cd $GOPATH/src/github.com/multiformats/go-multiaddr
gx-go rw --fix # unrewrite the paths from the gx/... form to the github.com/... form
rm ./.gx/post-install # marker file we create when we "install" a gx package.

(you may be interested in this thread: https://github.com/ipfs/go-ipfs/issues/4831)

2 Likes
3

Thanks! It worked.

I hadn’t understood that gx-go was a tool one needs to call explicitly. I thought it was just a package which provided go hooks for gx.

I was even able to do:

gx-go link go-multiaddr{,-net}

which is a bit nicer than having to copy and paste the hashes.

I can’t say I’m a big fan of gx right now given how it messes up my working trees and hard codes dependencies in all dependant source files (rather than having a central dependency file, which would IMHO be a much saner design), but I’ll make do.

4

I hadn’t understood that gx-go was a tool one needs to call explicitly. I thought it was just a package which provided go hooks for gx.

In general, you don’t have to call it. Only for special cases like this.

which is a bit nicer than having to copy and paste the hashes.

I’ve had bad experiences using package names with gx so I don’t by policy (bugs…). But yeah, that should work.

I can’t say I’m a big fan of gx right now given how it messes up my working trees and hard codes dependencies in all dependant source files (rather than having a central dependency file, which would IMHO be a much saner design), but I’ll make do.

I agree. I’d like to do what NPM does (except use hashes instead of versions when “locking” dependencies). Unfortunately, this takes time.

On the other hand, modifying a single gx dependency does wonders for my github activity…

1 Like