New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mijia opened this Issue May 12, 2015 · 4 comments

Comments

Projects
None yet
3 participants
@mijia

mijia commented May 12, 2015

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 comment has been minimized.

Contributor

davecheney commented May 12, 2015

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 davecheney added the question label May 12, 2015

@davecheney

This comment has been minimized.

Contributor

davecheney commented May 12, 2015

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

This comment has been minimized.

mijia commented May 12, 2015

Crystal clear, thank you very much.

@mijia mijia closed this May 12, 2015

@ches

This comment has been minimized.

Contributor

ches commented Sep 19, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment