constabulary / getgb.io Goto Github PK

gb test -coverprofile cover.out is failing with the following error:

testing: cannot use -test.coverprofile because test binary was not built with
coverage enabled
FATAL: command "test" failed: exit status 2

Is there any workaround at the moment?

Topnav should include some form of breadcrumb navigation.

The getting started page http://getgb.io/examples/getting-started/ has a number of interesting examples in the "converting an existing project" section where it uses git clone to populate the vendor/src directory. However, the examples stop at building the result and don't show how to commit the whole project in the end back into a git repo. A simple git add .; git commit doesn't work because the result would be that the repo would have a bunch of submodules for everything that was git cloned into vendor/src, which defeats part of the whole vendoring. Is one supposed to run rm -rf $(find vendor/src -name .git) before the git add? That loses all info about where the sources came from ... I know that some of this is "beyond the scope of gb" but not talking about it in the examples makes new users stumble and wonder whether this gb thing really works... (Not trying to bash gb, I'm thankful for you trying to wrangle the beast down!)

All pages have the title gb, this is bad for seo and bookmarking.

Hook up news/ RSS feed

In the FAQ (content/faq/externals.md) you clearly mentioned you disagree managing a copy of dependencies in project code base.

The Go authors agree that vendoring, taking a copy of your dependencies, is the path to repeatable builds – we just disagree on the method.

The Go authors are recommending vendoring by copying the source of your dependencies into a folder inside your package, then rewriting the source of those vendored depdendencies to accomodate.

Then please do NOT lead people to do that in the "getting started" guide (content/examples/getting-started.md) (the "Wrapping up" section):

you should check your $PROJECT directory into a source control repository. This includes any source you have copied from other projects into your $PROJECT/vendor/src/ directory.

I just started learning golang and got here when trying to pick the best dependency management tool out of the ~20 tools (!). Turns out a lot of tools recommend to copy dependencies and check into project source tree. I personally strongly disagree with that, I'd rather manage links to dependencies in project source tree, either using git submodule/subtree or tools like gom. If your opinions remain the same as mentioned in the FAQ, giving some more detailed examples would be very helpful.

Thanks for the great tool!

It may seem ornate, but consider what happens when someone vendors your code.

It's also important to not have your packages shadowed by the standard library. $PROJECT/src/log will never be compiled as it is shadowed by $GOROOT/src/log

I suggest CC-SA

The Go authors are recommending vendoring by copying the source of your dependencies into a folder inside your package

That's true.

then rewriting the source of those vendored depdendencies to accomodate

That's no longer true with vendor experiment (which is no longer experiment).