Supermighty

Supermighty muses philosophical on technology, programming, society, art, and the making of things. He has responsibilities in Walled City.

Building Go projects with gb

Sähköä ilmassa sunset behind power lines
Image courtesy of smerikal

gb is a new build tool for Go created by Dave Cheney. It address the problem of reproducible builds. Building the same functional binary anywhere at any time is a problem of dependency management. Of knowing exactly which library version to use, and having it at hand. gb is a radical tool compared to current dependency solutions, which work with the existing Go toolchain and idioms. gb takes a different approach, it replaces not only dependency management tools, but the Go build tools themselves. Instead of using go build or go install you would use gb build.

Dependency management in Go has always been a little wonky, a little weird. From the beginning there was go get but no other specific tools or process. go get infers a location from the import path about where libraries live, and grabs them. Placing them ever so lovingly in the src directory along side project code. go get knows enough about DVCS to grab the HEAD code, but not much more. There are no options for specifying which, if any, versions should be used, or commit hashes to checkout. The idea was to simply keep everything up to date manually. Keeping everything at HEAD sounds nice, but in practice it has proved problematic.

Realizing this wasn't a good long-term solution, the Go Team called upon the community to develop ideas and play with solutions. A wonderful idea indeed; practicing and playing will give us better solutions than just pie in the sky thinking would. The results of this are now coming to fruition, the Go Team has called for Vendoring to be the community's solution to dependency management. They called for a consensus to be reached on a file format for tools doing to dependency management to interoperate.

The idea behind gb

gb's solution for reproducible builds is based on the idea that the go get command, and associated handling of dependencies, is fundamentally flawed. gb suggests a new way to handle dependencies and build Go applications.

gb replaces go build because it has to. gb stores Go code in two places; first in $GOPATH/src where main.main() is, this represents the project, and then in $GOPATH/vendor/src where 3rd party dependencies are kept. gb looks in both of these location when building the project binary, where go build does not.

Project Based

gb works on projects. A project is "defined as any directory that has a src/ subdirectory."

~/myProject/src and $GOPATH/src are two examples, each one it's own project.

To gb a project is an end goal, not to be consumed by other code. Not to be imported and used. Projects are not go get'able. They are where main() lives, they compile to a binary you intend to run.

No configuration

gb does not use a configuration file, the source and code structure alone is enough to build a project. Dave Cheney is not opposed to having one; in fact he would rather have one than not. But opted to go without due to lack of consensus by the community on the format.

Respect the Source

gb does not do any import rewriting. This is because it has two separate locations for code. gb checks in both src and vendor/src when looking for the source of an import, where go build does not. Tools like godeps have to rewrite import paths for its vendored libraries otherwise the build when fail when go build can't find them.

I like that I don't have to do import rewriting for my dependency's dependencies. I want to use a library and never have to change it from what the upstream devs intended. This hands-off approach carries over to canonical import paths as well. They are left untouched.

I really like that 3rd party code is separated out into its own directory, and all libraries are flatly organized in that directory. I can look at vendor/src and see all of my dependencies. I don't have to go hunting and pecking for a vendored package of a vendored package.

Reproducible Builds

The main goal for gb is reproducible builds. It manages this by vendoring. Which takes libraries the project needs and makes them a part of the gb project, and commits them to the projects source control repository. Vendored packages are stored in $PROJECT/vendor/src/.

Any new checkout of the project will have all dependencies needed to build. If one is so daring there you can use git submodules/subtrees to store the dependeny’s history.

Dependency Versioning

gb, in it’s current state, does not manage dependency or which version are used. Rather it delegates this responsibility to gb-vendor, a plugin to the main gb tool.

gb-vendor itself is not special; it is a wrapper around go get -d. It’s only purpose is to grab dependencies that are go-get’able and drop them into the project’s vendor directory at $PROJECT/vendor/src/

gb-vendor is a quick proof of concept that Dave threw together. It lacks many features of a tradition DVCS; which puts it in a tricky position. What is gb-vendor’s role in managing dependency version and how much work should it do before pawning off to a proper DVCS.

Usage

gb is straightforward to use. First you vendor your dependencies, then you build your application.

cd myPackage
git init
gb vendor github.com/thirdParty/lib
gb build myPackage/myApp
git add ./
git commit

or you can use gb build all to build everything in your src directory.

A note about gb vendor; it was a quick plugin that Dave threw together to make his talk go smother. It may or may not stay around. What it actually does is in flux, and its future really depends on how developers use it, and want to use it. There is an open ticket on github for discussing `gb vendor'.

You can find detailed examples in the getting started documentation on github.

A turn in the road

I like gb. I've played with it for a couple of days, and it aligns with my personal preferences for Go development and project structure; more so than other dependency solutions currently available. It feels light-weight. It gets out of my way, and lets me manage my code without interfering. It feels good.

gb feels like a departure of sorts; but it isn't so different than the core Go assumptions about code structure. Rather it looks at them in a different way. I can't help but feel that this is some sort of significant moment in Go history. One we will look back upon; with reverence or trepidation I don't know, only time will tell. For now, though, I will use it to build my projects.

Continue reading ...

Understanding Go Dependency Management

lego blocks, dependency management
Image courtesy of kreezzalee

Right now there is a discussion thread on the golang-dev mailing list about formalizing how Go manages dependencies. The Go Team is putting forward that Go use vendoring to manage dependencies, and asked the community to formalize a configuration format that tools can use to manage vendored code.

Continue reading ...

The iOS keyboard is terrible

Can you tell which one of these keyboards will input uppercase or lowercase letters?

The iPhone, and iOS, brought about a revolution in mobile network connected pocket computers. It did a lot of things right, but it did one thing terribly wrong. When using the keyboard the letter on the key does not show the true character that will be input. The letters on the keyboard are always capitalized, even when pressing the key will input a lowercase letter.

It has been a very long time since I've used an iPhone day to day, but this still annoys me. Simply put the lack of accurately displaying the key to be input, capital or lowercase, is a disgrace. In part because of the years that iOS devices have been around, and the years that this features has been available on many Android phone. Though most importantly because it was Steve Jobs himself who cajoled his competitors and their fixed, never changing, keyboards.

Continue reading ...

Galaxy Tab Pro 8.4 Review

Beautiful Tab Pro 8.4 screen.

Reading on mobile devices is something I have done for a long time. I have read novels on some low quality screens; such as the Palm III, with it’s spinach green tint. Recently I’ve been looking at trading up from my Kindle Keyboard to a device with a better reading experience. I wanted something that was comfortable while reading for long periods of time, had a better screen, and access to more books and articles than the Kindle.

In the Samsung Galaxy Tab Pro 8.4 I have found a great device that give me joy to use. It is comfortable to hold, has a super sharp screen, and access to everything I’d want to read.

Read on for the full review.

Continue reading ...

Garny leather notebook cover

Leather notebook cover

Field Notes makes a quality notebook, but it's still paper and card stock. Given enough use it will become ragged, making it frail and eventually unusable. The solution is to write more often so that I use up a notebook before it starts to fall apart. While appealing, I do not want to be rushed with my words. So I found another solution, use a leather notebook cover.

Click through to the post for more images and my initial thoughts.

Continue reading ...