On 2016-07-16 11:22, Mauro Toffanin wrote:
On 16/07/16 01:43, Florin Pățan wrote:
I feel this is a controversial statement.
Godep can do this just as well, in fact any vendoring tool can do this,
as long as you commit your dependencies.
That is not true. Dave Cheney explained it very well at GDG Berlin
Golang DevFest: https://www.youtube.com/watch?v=c3dW80eO88I (see at ~15:00)
Interesting...
It's somewhat the same as we use:
* Don't use "go get"
* Have GOTPATH=${PWD} in project root.
* Have a /src directory in the project containing a link to project root
(often ../..) at the package name.
* Use gvt for vendoring everything into /vendor
... and you are free to do as any other non-go project.
I ended up with this since I had a multi-language project which I needed
to build debian pakcages too. And I could fulfill all the laguagees
different "demands" for layout (incl. go) at the same time as having
deb-helper recognize the build systems.
But the above makes it work and doesn't get in the way.
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.
In particular, I found the concept of 'import rewriting', used by
countless of package managers, quite irksome and in direct opposition to
the very same concept of a "reproducible build". You have no idea how
many times I have been bitten by the disruptive behaviour of the 'import
rewriting' of those package managers, much to my frustration and dismay.
Yeah... the idea of rewriting import paths has always felt like a bad
hack of a workaround.
/Peter
--
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.
