Should I use gb if I am working on go library?

[mijia]

gb is really an awesome project and I really like where gb is leading. My question is can I use gb for developing go library with vendoring other 3rd party libs, then how the dependency could be managed if the client is also using gb to build. What if my lib and my client projects depend on same another library but with different commit hashes?

Thank you very much.

[davecheney]

This is related to #49

The short answer is you can vendor one gb project inside another -- just copy the code from your $PROJECT/src/ into the downstream project.

Vendoring dependencies is similar, you'll need to merge the contents of your libraries $PROJECT/vendor/src/ into the downstream's vendor directory.

Unfortunately gb cannot help you with this as Go projects don't have any concept of versions, there is no way you can look at the source of a Go package and ask it "what version are you" (assuming something like SemVer). Now you might have commit hashes for both copies of a particular package you are vendoring, and you might be able to take those commit hashes and look them up in the source repository and say "hash abced is newer than hash ed3fc".

Ultimately this is down to the project owner, the one consuming the code, not the library developer, the one producing the code, to solve.

I'm sorry I don't have a stronger answer for you, Go packages simply don't have the version information available to assist the project owner.

[davecheney]

I want to add that if your organisation is happy to use tools like git submodules, or git subtrees, then this can make it easier for the downstream project to at least know which two revisions of a vendored dependency they are dealing with.

gb does not mandate the use of git subtrees or submodules, all it cares about is the source is present inside $PROJECT/src and $PROJECT/vendor/src.

[mijia]

Crystal clear, thank you very much.

[ches]

Since the official gb FAQ links to this issue for background, I wanted to note here that @davecheney pointed out elsewhere in a blog post that gb-vendor could be enhanced to facilitate this, and that sounds like a nice idea to me:

At the moment no automated tools exist to assist with this process, but it is likely that gb-vendor will acquire this ability if there is significant demand in developing libraries in the gb project format.

I might take a stab at that, time allowing. If that takes awhile, maybe someone else reading this thread will do it quicker 😄

Also #49 is a good read worth cross-referencing here.