> You would be surprised to know that gvt uses gb internally,
> and both the projects exchange pieces of code and ideas ;)
That's not the impression I get. I might be wrong, but I believe that gvt
does not share most of gb's philosophy: 1) It is based on just gb-vendor, not
the rest of gb. 2) It uses Go's vendor directory without the top-level (single
project) restriction, and in a manner which is compatible with the go tool (no
vendor/src). 3) It uses the go tool, not the gb replacement tool. 4) It uses,
rather than ignores, GOPATH. 5) It provides some support for versioning.
John
John Souvestre - New Orleans LA
-----Original Message-----
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Mauro Toffanin
Sent: 2016 July 16, Sat 10:59
To: golang-nuts@googlegroups.com
Subject: Re: [go-nuts] What dependency management tool do you use?
On 16/07/16 15:16, Peter Mogensen wrote:
> * Use gvt for vendoring everything into /vendor
You would be surprised to know that gvt uses gb internally, and both the
projects exchange pieces of code and ideas ;)
> But wrt. to the talk above: Didn't Dave Cheney dismiss the diamond
> problem a little too fast? Sure you "cannot" do that, but you can still
> end up in a situation where you depend on 2 different libraries, each
> which depends on different specific version of the same 3rd package.
I actually agree with Cheney's decision:
http://dave.cheney.net/2015/06/09/gb-a-project-based-build-tool-for-the-go-programming-language
The probability of encountering a diamond dependency conflict is so low
that makes sense to treat it like a corner case and to force the final
user to manually take action; providing some boiler-plate solver will
never guarantee a valid consistent resolution for every single
conflicting case, leading only to an increased complexity� of the tool.
Automatically solving the diamond dependency conflict requires tampering
with the Golang source code anyway, which means we are back to the
square one with dirty work-arounds: with source code tampering you lose
the "reliable" and "reproducible" part of your builds.
One could argue that solving the diamond dependency in an automatic way
has benefits per se. I can understand the allure of that reasoning, but
it's not the Go way of doing things; it's like with Generics: some
people like them and want them, some others don't and prefer to stick to
manual implementation.
There isn't an easy answer to such problems.
�- you have to deal with graph theory, implement Breadth First and Depth
First algorithms, impose barriers and fences all over the PM; I
personally don't see the advantage considering its complexity vs the
little outcome. It's easier, and faster, to manually solve the conflict.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
