Current use of gopkg.in is impossible to use

[jdoklovic]

@bzz @smola @mcuadros

I have no problem with gopkg.in, however, the way it's currently used in this project makes it difficult if not impossible to develop against.

The main problem is that master uses gopkg.in/v4 imports, yet the v4 branch is 30 commits behind master at the moment. This effectively means it's difficult to tell which code is actually being used and even hard to make any local changes and/or PRs.

I think it would be better if master only used github/src-d imports and reserve the gopkg.in for the versioned branches.

[osklyar]

You can simply clone master under $GOHOME/gopkg.in/src-d/go-git.v4 if you want to work on it or if you want to use it in your project with go get. If you are using one of dependency managers such as dep or glide then simply specify that the source of gopkg.in/src-d/go-git.v4 should be taken from https://github.com/src-d/go-git along with the corresponding revision, e.g. for dep in Gopkg.toml:

[[dependencies]]
  name = "gopkg.in/src-d/go-git.v4"
  revision = "727bf94da8e3cebd3ff467d30425b12d671fbca7"
  source = "https://github.com/src-d/go-git"

[jdoklovic]

@osklyar thanks, that makes sense... They should definitely be part of the main readme

[jdoklovic]

I still find it jarring that one cannot simply grab master and go (so to speak). Seems like the gopkg.in should be reserved for stable/tagged releases and not for development/master/tip code

[osklyar]

I agree it is cumbersome, but I would not necessarily see a better option right now. How do other libraries do that?

[jdoklovic]

They just use normal branches and tagging and nothing like gopkg.in they leave it up to consumers to choose they dependency/version management of choice

[jdoklovic]

What problem is gopkg.in solving for this project that simple tags don't?

[osklyar]

I mean other projects that do use going.in? I would also recommend to release next version directly via a tag on github, but the current one is already elsewhere.

[jdoklovic]

I think projects used gopkg.in before 1.6 when vendoring support was added. Now I find projects are discontinuing it's use. see: go-kit/kit#197

[smola]

We will continue using gopkg.in in the near future for v4. We'll switch to GitHub imports when go dep is ready, and that will probably be for go-git v5.

Most of the go-git team develops by using git directly on $GOPATH/src/gopkg.in/src-d/go-git.v4. You can easily do this with git clone [email protected]/src-d/go-git.git $GOPATH/src/gopkg.in/src-d/go-git.v4.

Of course you can also use a vendoring tool as @osklyar suggests.

[jdoklovic]

You can't really use a vendoring tool... that's the problem. It's fine if you're developing go-git, but if you're trying to make changes to go-git and consume them in another library, it becomes painful. I use glide and it takes some work to get it to pull from my go path instead of the internet sometimes.
At any rate, moving to git imports in v5 will be welcomed. in the meantime, can we at least get v4 branch rebased with master sometime soon?

[osklyar]

@jdoklovic See my very first response: it is the counter example to your statement of "you can't really use a vendoring tool..." – fork and point dep to your forked source. I did this all the time putting temporary workarounds while my bug reports were being addressed.

[gonzaloserrano]

git clone [email protected]/src-d/go-git.git $GOPATH/src/gopkg.in/src-d/go-git.v4

Indeed that's the only way to be able to use the lib after v4 because if you try the "usual" ways, which are go getting:

• github.com/src-d/go-git: that won't work cause it gets master, and in master import paths point to gopkg.in v4.
• gopkg.in/src-d/go-git.v4: that won't work cause master in that repo points to v4 so you won't get the changes from current master from github.com/src-d/go-git

edit: in fact the correct command is git clone [email protected]:src-d/go-git.git $GOPATH/src/gopkg.in/src-d/go-git.v4
edit2: and then go get github.com/src-d/gcfg

[jdoklovic]

@gonzaloserrano @osklyar @smola not to beat a dead horse, but until the v4 branch is rebased with master, this is still impossible for me to consume. I understand how I can work around it locally, but I'm building a CLI tool that people can install using go get -u myclitool The problem is that as @gonzaloserrano explained, this is going to pull down the gopkg.in v4 code which doesn't have the bits I need that are currently only in master.
I'm just suggesting that v4 be rebased with master in the very near future and then move forward with "normal" imports for v5

[smola]

@jdoklovic v4.0.0-rc10 is out: https://github.com/src-d/go-git/releases/tag/v4.0.0-rc10

[jdoklovic]

@smola awesome! thanks.