gb vendor updating dependencies

[ukiahsmith]

Do you see gb vendor as a one time operation to grab dependencies; then use that libs DVCS native update function for the infrequent times when the library needs changes from upstream?

Could gb vendor receive add functionality similar to what go get has? Does it need them?

[davecheney]

There are two paths that I see for this plugin, which was written very much as a proof of concept, and also to be able to demo on stage; not necessarily in that order. I am concerned that it's existence distracts people from the main goal of gb.

1. delete the plugin, it's confusing, and teach people who to checkout directly
2. enhance the plugin with options for -tag -branch, etc, and to let it update, etc, that also means teaching it all the dvcs's that go get knows, and maybe even about vanity imports.

Although these are different amounts of work, it is not clear which is the better solution. gb vendor would have to grow an awful lot to be the go get that everyone really wanted, maybe it's simpler to just delete it.

[ukiahsmith]

I think that gb vendor isn't needed. Everything it does can be done by other tools, that--most likely--will be installed. So point 1 makes sense.

But, I think from a psychological-branding-marketing angle it's nice to have have a tool that is analogous to go get and easy tell people about. A: how to do dependencies? B: use gb vendor

• Is there anything gb vendor could do that the DVCS could not, or not as well?
• Is there a benefit to using gb vendor in built tools (make, et al) over a DVCS?
• Is there a benefit to only interacting with gb vendor instead of multiple different DVCS for different dependencies?

[davecheney]

The problem is I didn't do a good enough job with gb vendor, I just hacked it up to demo at GDG Berlin. My intentions were in the right place, I didn't want to distract people with git checkouts and creating the paths to place source code in the right place, as this can easily be gotten wrong and will frustrate.

But, with that said gb vendor is a victim of it's success, it gets you started, then leaves you stranded.

What I will do for now is add another section to getting-started.md that shows how to setup a project without using gb vendor, but leave the plugin in place for now.

Hopefully in the future, with more information about how people are using it, gb vendor can be enhanced to do all the things that Rails' bundler does, which is probably a good model to work towards.

[jbuberel]

FWIW, I agree with @Supermighty about the gb vendor command. It is a distraction. I am also a fan of "do one thing really well" principle.

For gb that boils down to:

• Provide the project-like simplicity of a single, top-level directory
• Make it easy to manage multiple src roots for things ilke vendored code.

[davecheney]

It would seem that gb vendors days as a plugin in it's current form are
numbered.

I'm planning on setup a propery github site for gb, with proper
documentation, some background information (mostly cribed from the original
presentation) and more examples. That will probably be the point when gb
vendor gets the chop.

On Sun, May 3, 2015 at 11:04 AM, Jason Buberel notifications@github.com
wrote:

FWIW, I agree with @Supermighty https://github.com/Supermighty about
the gb vendor command. It is a distraction. I am also a fan of "do one
thing really well" principle.

For gb that boils down to:

• Provide the project-like simplicity of a single, top-level directory
• Make it easy to manage multiple src roots for things ilke vendored
  code.

—
Reply to this email directly or view it on GitHub
#29 (comment).

[jbuberel]

That being said, the documentation will need to help educate users on why not being able to use go get is actually a good thing. They'll need to be shown examples of how to structure projects and use other retrieval tools (that are perhaps cross-DVCS-compatible for retrieving code into specific directories.

I can help with that sort of stuff.

[davecheney]

Precisely, gb vendor, however flawed, solved the issue of checking out
the source in exactly the right location.

On Sun, May 3, 2015 at 11:09 AM, Jason Buberel notifications@github.com
wrote:

That being said, the documentation will need to help educate users on why
not being able to use go get is actually a good thing. They'll need to be
shown examples of how to structure projects and use other retrieval tools
(that are perhaps cross-DVCS-compatible for retrieving code into specific
directories.

I can help with that sort of stuff.

—
Reply to this email directly or view it on GitHub
#29 (comment).

[ukiahsmith]

Let me clarify my position. I believe we need the gb vendor tool. Or something like it.

• Having it makes it easy to get started with gb for new users.
• having it makes it easier for casual users.
• having it makes it easier to integration with automated tools.

David you lamented in another issue that people didn't adopt the "multiple src directories in one $GOPATH" style of dependency management. The reason they didn't is because there was no tool that did it for them. Having gb vendor will go a long way to help people adopt that style.

[jbuberel]

That's a good point. What makes go get magical to first time users is it's ability to retrieve the code you asked for and then all of it's dependencies across a wide variety of DVCS systems.

For gb to be successful, there needs to exist a tool that can effectively replace that user experience. But will do it in a way allows it to be used with tools and projects like gb.

I guess I'd just assumed that such a beast existed, but that probably means I haven't looked hard enough.

[jbuberel]

Perhaps gb vendor should become a separate tool/project (github.com/constabulary/gv)?

The more I think about it, the more I agree with @Supermighty. At the same time, I suspect that until gb vendor is feature complete enough to replace go get - fetching all dependencies - it will be a source of many bugs and feature requests.

[davecheney]

I agree. This was why I started with a plugin system. I'll move the vendor
plugin to constabulary/gb-vendor once I consider gb more feature complete,
which means basic cgo support and support for external tests.

On Mon, 4 May 2015 00:32 Jason Buberel notifications@github.com wrote:

Perhaps gb vendor should become a separate tool/project (
github.com/constabulary/gv)?

The more I think about it, the more I agree with @Supermighty
https://github.com/Supermighty. At the same time, I suspect that until gb
vendor is feature complete enough to replace go get - fetching all
dependencies - it will be a source of many bugs and feature requests.

—
Reply to this email directly or view it on GitHub
#29 (comment).

[ngrilly]

That being said, the documentation will need to help educate users on why not being able to use go get is actually a good thing. They'll need to be shown examples of how to structure projects and use other retrieval tools (that are perhaps cross-DVCS-compatible for retrieving code into specific directories.

@jbuberel, what are the other retrieval tools you would use?

[jbuberel]

@ngrilly I may need to retract that earlier statement. I've now been testing out a few other tools, like godep, and I haven't come across anything that would be an effective replacement for what gb vendor aspires to be.

And I don't believe that asking users to use DVCS-specific commands (git clone) is a reasonable path either.

For these reasons, I find myself falling back on @davecheney's original motivation for including gb vendor - there really aren't any good alternatives.

[ngrilly]

@jbuberel I haven't found any tool that really solves the issue either. This is why I was intrigued ;-)

That said, I use the same structure as gb for my internal projects (a src directory for the app and a src directory for the dependencies, both committed at the root of our project source code) and it happens go get is quite good at doing the initial fetching of dependencies. The issue I had with go get is manually getting rid of the DVCS directories (.git, .hg, etc.) before committing the vendor directory, which can be an error prone process. [1] This is a place where godep (for example) shines. The good way to solve this to invoke go get in a temporary GOPATH and then copy the relevant stuff to vendor/src, without the DVCS dirs.

But I agree with Dave that there is the issue of where to draw the line. For example, should the vendoring plugin be able to report the status of each dependency compared to the last available version? Should it be able to upgrade dependencies? Should it be able to pin versions?…

[1] https://www.digitalocean.com/company/blog/taming-your-go-dependencies/