search

bitfinexcom / bitfinex-api-go

BITFINEX Go trading API - Bitcoin, Litecoin, and Ether exchange
https://www.bitfinex.com/
MIT License
309 stars 220 forks source link

Can not use "go get" #112

Open Raincle opened 6 years ago

Raincle commented 6 years ago

I just ran "go get github.com/bitfinexcom/bitfinex-api-go" as it said in readme, but it doesn't work. How can I solve this problem?

image

brobits commented 6 years ago

the readme should be updated, thanks for identifying this. try cloning the repository with git clone git@github.com:bitfinexcom/bitfinex-api-go, cd bitfinex-api-go, & go install ./...

jvatianou-connamara commented 6 years ago

This should be closed since the README is updated.

Raincle commented 6 years ago

@jvatianou Are you serious???

Raincle commented 6 years ago

@brobits image

brobits commented 6 years ago

@Raincle you're placing your source in a non-standard path, this is outside the scope of this project.

Go source typically lives in ~/go/src, in this case, the repo should be cloned in the directory at ~/go/src/github.com, and your GOPATH should point to ~/go.

See https://github.com/golang/go/wiki/SettingGOPATH

jvatianou-connamara commented 6 years ago

adding the 'help wanted' tag and moving to 'in progress' pipeline.

@Raincle have you experimented with the link that @brobits provided?

wyaeld commented 6 years ago

@brobits @jvatianou The very first lines of the readme still claim you can use Go get, which we know doesn't work.

Is there actually a rationale for having it packaged in a non-standard way like this? I can see you have v1 and v2, and they both might need long-term support, but its far more typical to have the master branch at your current version, and a v1 branch which has the earlier. I believe if done that way it could follow standard conventions and still work for everyone.

Related, but I'd like to get feedback on addingdep for managing dependencies now that it is the standard choice for golang. Its what I use local when developing on this, I just don't commit it.

brobits commented 6 years ago

I would be careful about relying on dep. From the dep readme:

dep was the "official experiment." The Go toolchain, as of 1.11, has (experimentally) adopted an approach that sharply diverges from dep. As a result, we are continuing development of dep, but gearing work primarily towards the development of an alternative prototype for versioning behavior in the toolchain.

Go's current stable release is 1.11. As a dev familiar with Golang development, you probably already know this, but the Golang team has been struggling to make up its mind on a dependency solution (go get, vendoring, dep, etc). Dep is on its way out, and the next experiment has already been released in the current version: Go modules.

I think it's early to consider migrating dependency management to the latest experiment, and I'd err on the side of caution.

Having said this, yes, v1/ and v2/ endpoints are messy in the source tree, and I agree they should be cleaned up so everything can build via go get.

wyaeld commented 6 years ago

@brobits happy with that reasoning on dep. Go has done well by moving with caution, and dependencies aren't a big issue on this project.

How about this as a branch structure.

1) tag the current as combined-sep-2018 That way anyone relying on the current repo layout isn't directly impacted, but keep it as a transitional thing only, hence tagging the point and not branching. 2) strip everything not related to v2 out of master and make it go get capable 3) branch for v1 and strip everything not related to v1 out of it, make that also go get capable.

With update readme to explain.