[pkg-go] a mutual dependency problem (Packer)

[Daniel Stender]

On 15.04.2016 02:10, Dmitry Smirnov wrote:
> On Thursday, 14 April 2016 10:38:15 PM AEST Daniel Stender wrote:
>> I have an idea but wanted to poll, how could get they both in the best way?
>  
> Not sure for "best way" but here some ideas how this problem could be 
> addressed:
> 
> Sometimes one dependency required only by tests. In such case it may be safe 
> to disable corresponding tests in order to break/remove circular dependency.
> 
> Since Packer appears to be a bigger package it is likely that you are 
> packaging "winrmcp" merely to satisfy dependency of Packer. There are two 
> options:
> 
>  * To keep bundled/vendored version of "winrmcp" in Packer and do not package 
> "winrmcp" separately;
> 
>  * To keep bundled/vendored portion of Packer code in "winrmcp".
> 
> I would investigate those options in given order. Whatever you choose please 
> remember to leave a note explaining your decision in README.source.

I've solved the problem at winrmcp with a patch which injects the needed code, and upstream
in the meanwhile was so nice to break the circular dependency by using another UUID package.

Packer itself has another problem, the lately packaged update of azure-sdk (2.1.1~beta, 2016-04-12)
already breaks Packer 0.10.0, which vendors 1.2+334-95361a2 (2016-02-10).

Do people have pointers to Go packages already in the archive by the hand which are vendoring
some third-party code which could work as a model how to solve this?

Thanks,
DS

-- 
4096R/DF5182C8
http://www.danielstender.com/blog/