Open Stack

On 12/13/2016 04:45 PM, Dean Troyer wrote:
> On Tue, Dec 13, 2016 at 4:26 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>> Not sure if it's already been brought up, but I really like govendor:
> 
> Govendor and glide are the two most promising candidates at this
> point.  I just read today's summary of the Package Management
> Committee [0] and that sounds _really_ promising, if further out than
> we can wait on, but there will be migration paths from many of the
> existing tools.  Both govendor and glide have devs in the Advisory
> Group to the committee.

Yup - looked at govendor, glide and godep back in May:

https://review.openstack.org/315200 - glide
https://review.openstack.org/315196 - govendor
https://review.openstack.org/315029 - godep

>> 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.
> 
> This is the intention and I see no reason why it is not achievable.
> It totally depends (ha!) on having better (any!) dependency management
> in place.

++

I think we're all fairly well agreed on not vendoring code in OpenStack.
IANAL but I also think our CLA would make a patch to vendor code into an
OpenStack repo particularly legally strange. (a contributor quite simply
does not have the legal standing to apply the terms of our CLA to the
vendored code) I don't know for a fact that this is strictly
problematic, but given that it does seem at best grey, and the fact that
vendoring code is a TERRIBLE engineering decision, I'm pretty sure we
can steer clear of it.

I will be happy to write up such a policy if we think it would be good
to have one on the books?

> One thing that I have been pondering is resurrecting the old technique
> of embedding version info into binaries so they can be examined to
> discover which library versions were used in its build.  This was
> totally a thing when I was using rcs ($Id$ and ident(1) FTW) but that
> particular technique is messy with distributed version control, and
> may not be needed at all in a packaged distro environment.  This may,
> however, help ease the concerns many have around static linking of
> libs.
> 
> dt
> 
> [0] https://blog.gopheracademy.com/advent-2016/saga-go-dependency-management/
>