search

whyrusleeping / gx-go

gx subtool for golang
MIT License
80 stars 28 forks source link

[question] how to deal with gx hash conflicts? #40

Open adam-hanna opened 6 years ago

adam-hanna commented 6 years ago

I have a problem where one of my gx dependencies relies on an older gx dependency.

Here's the code in question:

package foo

import (
    cid "gx/ipfs/QmapdYm1b22Frv3k17fqrBYTFRxwiaVJkB299Mfn33edeB/go-cid"
    bserv "gx/ipfs/QmcKwjeebv5SX3VFUGDFa4BNMYhy14RRaCzQP7JN3UQDpB/go-ipfs/blockservice"
    ...
)

func Bar(bs bserv.BlockService, c *cid.Cid) (*Bar, error) {
    data, err := bs.GetBlock(ctx, c)
    ...
}

I'm getting the following error on the line data, err := bs.GetBlock(ctx, c):

cannot use c (type *"gx/ipfs/QmapdYm1b22Frv3k17fqrBYTFRxwiaVJkB299Mfn33edeB/go-cid".Cid) as type *"gx/ipfs/QmcZfnkapfECQGcLZaf9B79NRg7cRa9EnZh4LSbkCzwNvY/go-cid".Cid in argument to bs.GetBlock

My go-cid hash is at the latest, and so is my go-ipfs hash. However, I can see that release v0.4.15 of go-ipfs is using a different hash of go-cid (QmcZfnkap...). The same hash as the one given in the err.

What's the recommended gx-go way of dealing with this problem? Thanks!

schomatis commented 6 years ago

@adam-hanna Sorry for the delay we're currently working on it in https://github.com/whyrusleeping/gx-go/issues/46, in the meanwhile there's no standard fix, we normally temporarily changed the dependency of the linked package being developed to match the dependency in go-ipfs and then revert that change when committing (although that's far from an optimal solution).