Skip to content
This repository has been archived by the owner. It is now read-only.

gb vendor updating dependencies #29

Closed
ukiahsmith opened this issue May 2, 2015 · 17 comments
Closed

gb vendor updating dependencies #29

ukiahsmith opened this issue May 2, 2015 · 17 comments
Labels

Comments

@ukiahsmith
Copy link

@ukiahsmith ukiahsmith commented May 2, 2015

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 davecheney added the question label May 2, 2015
@davecheney
Copy link
Contributor

@davecheney davecheney commented May 2, 2015

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
Copy link
Author

@ukiahsmith ukiahsmith commented May 2, 2015

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
Copy link
Contributor

@davecheney davecheney commented May 2, 2015

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
Copy link
Contributor

@jbuberel jbuberel commented May 3, 2015

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
Copy link
Contributor

@davecheney davecheney commented May 3, 2015

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
Copy link
Contributor

@jbuberel jbuberel commented May 3, 2015

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
Copy link
Contributor

@davecheney davecheney commented May 3, 2015

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
Copy link
Author

@ukiahsmith ukiahsmith commented May 3, 2015

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
Copy link
Contributor

@jbuberel jbuberel commented May 3, 2015

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
Copy link
Contributor

@jbuberel jbuberel commented May 3, 2015

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
Copy link
Contributor

@davecheney davecheney commented May 3, 2015

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
Copy link

@ngrilly ngrilly commented May 5, 2015

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
Copy link
Contributor

@jbuberel jbuberel commented May 5, 2015

@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
Copy link

@ngrilly ngrilly commented May 5, 2015

@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/

davecheney added a commit that referenced this issue May 10, 2015
Update #29

gb-vendor has moved to it's own repository, github.com/constabulary/gb-vendor. Our upcoming website will highlight that gb-vendor is an _addon_ and not part of gb. Hopefully this will help simplify the message.
@oconnor663
Copy link

@oconnor663 oconnor663 commented May 28, 2015

Shameless self-promotion: If you're looking for a general retrieval tool that supports pinning and updating pins, you might like peru. It doesn't know anything about Go, so you would want something Go-aware to generate peru.yaml files. It's also written in Python 3, which you might or might not be comfortable with as a dependency.

@jbuberel
Copy link
Contributor

@jbuberel jbuberel commented May 28, 2015

@oconnor663 Thanks for the tip. That does do much of what a 'proper' version-aware third-party downloader should do. Very nice. Of course, the Go community being the Go community would make the Python part a very hard sell :-)

@davecheney
Copy link
Contributor

@davecheney davecheney commented Jun 3, 2015

We now have gb vendor update.

@davecheney davecheney closed this Jun 3, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.