On 12/13/2016 03:17 PM, Monty Taylor wrote:
On 12/13/2016 12:45 PM, Dean Troyer wrote:
I am working on scoping the tasks required for the technical pieces of
Golang adoption in OpenStack. This work has been informed somewhat by
flaper87's reference doc proposal[0] for new language additions and is
(mostly) compatible with it, pending that proposal's final approval by
the TC.
As a first step, I proposed a Common Testing Interface (CTI)
document[1] for Go. There is, of course, much more than this,
including a number of significant decisions that still need to be
made. At this point I want to focus on identifying those decisions
and other tasks rather than solving them immediately.
Some of the previous work done around using Golang in OpenStack has
been collected in an Etherpad[2] and summarized into major categories.
I am confident that I have not found everything that has been done and
would appreciate pointers to whatever resources you may have. Here
are some highlights of areas that still require discussion and
decisions:
Common Libraries
flaper87's reference doc touches on project requirements for new
languages and Oslo-compatible implementations. At the time of this
writing this is not yet finalized, with some discussion around how
much to require, and if the first project to utilize a new language
should shoulder all of the burden of also implementing those
libraries.
Dependency Management
There are a number of tools available for Golang to manage
dependencies. A number have been evaluated already with a couple of
strong contenders identified. Once a tool is selected, process needs
to be set up to track dependencies and versions tested.
Figuring out how to get from that to pre-cached git repos in gate nodes
is another important task. Actually cloning from github during CI jobs
leads to wailing and gnashing of teeth pretty quickly. That said - godep
and glide both lend themselves well towards doing such a thing.
Not sure if it's already been brought up, but I really like govendor:
https://github.com/kardianos/govendor
for Golang dependency management.
More than the decision between dependency management toolkits, though,
is the decision over whether to have *any* vendored source code in the
primary project's source tree itself (as opposed to only storing the
vendor.json/glide.yaml|lock file that lists dependent library versions
and locations). Please let's have a policy of keeping vendored source
code *out* of the primary project source tree.
Perhaps this is just me, but honestly, I don't see why some in the
Golang community seem to just want to throw away decades of best
practices from the development community that advises not to bundle all
your dependent library source code in your own project's source tree.
Basically... *don't mix your build artifacts with your source files*.
Best,
-jay
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
