Closed jbuberel closed 9 years ago
I was just wondering about this too.
One could create a plugin gb-get that actually creates a project directory and checks all the dependencies out to vendor/src.
something like this perhaps?
if [ -n "$1" ]; then
echo "project is required"
fi
project="$1"
mkdir -p "src/$project"
git clone "https://$project" "src/$project"
GOPATH=./vendor:. go get -u $project/...
But that does leave the versions bit unanswerred. for submodules it could perhaps use a file .gb or something that lists the modules required to build a project that is gb buildable. A bit like how godep does it.
perhaps a better approach to this is something like what people do with the gh-pages branch.
You have a develop branch. when you're ready to release, you push to a subtree which is actually your master branch
develop branch:
.
├── develop
│ ├── src
│ │ └── github.com
│ │ └── something
│ │ └── useful
│ └── vendor
│ └── src
│ └── github.com
│ ├── stretchr
│ │ └── testify
│ └── tav
│ └── golly
└── master -> develop/src/github.com/something/useful
I think this keeps it all in one repo, allows for repeatable builds and hopes for the best when you do go get.
For github you can set the default branch to develop and go get would still get the master branch.
@jbuberel
I am assuming this statement means more literally that 'gb projects can be retrieved, but not correctly installed, using go get'. Or are you making the stronger statement that developers cannot use gb to create Go libraries; it can only be used to create Go commands?
You are correct. This is a poor turn of phrase. What I was trying to say is using go get to fetch a repository containing a gb project will place the source in a layout that the go tool won't understand.
The second part of your question is, #49 and sort of covered in http://getgb.io/faq/library/.
What I should do is add an example to the examples section with graphs and arrows showing which pieces of a library project need to be transplanted (or embedded) into a downstream project.
@casualjim please see http://getgb.io/faq/why-not-wrap/ and also the long sprawling discussion in #42. Long story made short, if you want to wrap the go tool, use godep
.
@casualjim
perhaps a better approach to this is something like what people do with the gh-pages branch. You have a develop branch. when you're ready to release, you push to a subtree which is actually your master branch
This sounds a little tangental to the original question. You're starting to describe a process where Go programmers could release their code, which is not something that is commonly done at the moment.
I'm not saying this is not a good thing, just that it is unrelated to Jason's question. Could I ask you to take this tangent to a new issue ?
@jbuberel I wanted to keep http://getgb.io/rationale/ short, it's already too long for most casual readers, do you think that sentence can be addressed in place, or would it be better to write a faq/ and link to it from that page?
Actually I think it's the same as what's answered in the faq.
Both could probably do with some word smithing. Patches accepted (sincerely)
On Wed, May 13, 2015 at 8:05 AM, Ivan Porto Carrero < notifications@github.com> wrote:
Actually I think it's the same as what's answered in the faq.
— Reply to this email directly or view it on GitHub https://github.com/constabulary/gb/issues/78#issuecomment-101436098.
Closing this issue for the moment.
Just came across this line in the documentation on this page http://getgb.io/docs/project/:
I am assuming this statement means more literally that 'gb projects can be retrieved, but not correctly installed, using go get'. Or are you making the stronger statement that developers cannot use
gb
to create Go libraries; it can only be used to create Go commands?