Comments (17)
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.
- delete the plugin, it's confusing, and teach people who to checkout directly
- 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.
from gb.
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?
from gb.
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.
from gb.
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.
from gb.
It would seem that gb vendor
s 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 [email protected]
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).
from gb.
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.
from gb.
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 [email protected]
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).
from gb.
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.
from gb.
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.
from gb.
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.
from gb.
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 [email protected] 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).
from gb.
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?
from gb.
@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.
from gb.
@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/
from gb.
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.
from gb.
@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 :-)
from gb.
We now have gb vendor update
.
from gb.
Related Issues (20)
- gb should fail early with unknown/unsupported GOOS or GOARCH value
- Error vendoring gb with gb-vendor HOT 2
- gb build does not create bin folder and binary in bin folder HOT 24
- Website needs list of projects using GB
- Gogland (perhaps also others) configuration example HOT 1
- why vendor/src? HOT 1
- gb build fails on centos7 with linking error HOT 6
- have any command copy a package from $GOPATH
- Can't build project in Docker HOT 2
- gb build do not work correctly on windows (can work correctly on linux)
- Build of Go's runtime package fails when cross-compiling with go1.9.4 HOT 6
- horizon HOT 4
- using gb to make a library HOT 2
- Is the gb project dead? HOT 15
- / HOT 1
- gb vendor doesn't work with fish shell HOT 1
- [SOLVED] How to migrate to go modules? HOT 6
- gb + IDE ? HOT 1
- Cross build not working on OSX: cgo_export_static main only allowed in cgo-generated code
- module github.com/constabulary/gb@latest found (v0.4.4), but does not contain package github.com/constabulary/gb/internal/vendor HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gb.