Open Stack

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