Golang autocompletion for Docker packages

Warning: This will be probably be thoroughly uninteresting if you (a) aren’t hacking on Docker core code, or (b) are hacking on Docker but are happy with your own autocompletion setup for the Docker packages themselves.

Auto-completing Docker container functions in vim

I actually don’t know if this is solved via simpler methods, so forgive me if this is a waste of a blog post.  However, I fell into the common software developer’s trap of having an annoying problem with my development environment, and via the ever-present itch to find a solution, made up a solution of my own without doing a lot of consultation with other Docker developers.

In this case, after a few months of being a newbie to Go and searching around for all the right tools and plugins for my editor of choice (vim of course!), I was desirous of autocompletion for Go constructs, package functions, builtin APIs, and so on.

The nsf/gocode project seemed to have a good solution that worked well, including a vim plugin, so I immediately plugged that into my environment and happily continued on my much-improved-developer-self way.  What I realized soon enough was that gocode was only auto-completing symbols for which any element in the $GOPATH included objects within its pkg/$GOOS_$GOARCH subtree.  Given most Docker developers use the Docker container as the build workflow, any intermediate Go compiler output was not preserved in my host system’s Go environment, meaning no auto-completion for Docker packages.

Given I hack 0n Docker regularly but don’t write many Dockerfiles in my daily work, I took this as an opportunity to write a specific Dockerfile and script to do the work necessary to save the transient artifacts during a build of the Docker sources required for autocompletion with gocode.  I’m sure it can be improved and I would love feedback (or PRs!) from those inclined to check it out.  One easy modification would be to use the developer’s already-existing cloned tree of the sources (currently used by the Dockerfile in the main docker/docker project) rather than creating a clone of master during the Docker image build.  What other improvements would you make or what am I missing in general with this experiment?

Check out my dockompleter project on GitHub and let me know what you think.