Closed spacejam closed 9 years ago
yeah
That of course, because I did it myself too many times before, when not changing the GOPATH. I just think that the alternative is safer.
@tsenart I agree that it is destructive to manipulate anything in the real GOPATH, which is why the first section of the Makefile overrides this for anything that happens inside it. I've nuked the use of godep altogether as it is unnecessary.
Why is it unnecessary?
@tsenart because the Makefile sets GOPATH to where the dependencies are.
@spacejam: Sure, but with a single GOPATH we won't be able to guarantee reproducible builds. That's why we want vendoring in the first place.
This approach is similar to what k8s does at build time: create a build sandbox that deps are copied into, point GOPATH at the sandbox, and then build it. I'm fine with this.
On Fri, Aug 14, 2015 at 1:03 PM, Tomás Senart notifications@github.com wrote:
@spacejam https://github.com/spacejam: Sure, but with a single GOPATH we won't be able to guarantee reproducible builds. That's why we want vendoring in the first place.
— Reply to this email directly or view it on GitHub https://github.com/mesosphere/etcd-mesos/pull/27#issuecomment-131181253.
@jdef I took out the part that copies the deps to a temporary directory, and just uses the Dodep directory as GOPATH in the interests of saving initial compile time. Is this a bad idea?
What do you think about requiring go1.5 and re-working the vendoring to leverage that?
It looks like the latest godep has support for it: https://github.com/tools/godep
On Wed, Aug 19, 2015 at 10:25 PM, Tyler Neely notifications@github.com wrote:
@jdef https://github.com/jdef I took out the part that copies the deps to a temporary directory, and just uses the Dodep directory as GOPATH in the interests of saving initial compile time. Is this a bad idea?
— Reply to this email directly or view it on GitHub https://github.com/mesosphere/etcd-mesos/pull/27#issuecomment-132856733.
@jdef I think that's a nice feature, but I'm not sure if that would restrict the usability of this for a good reason. A lot of places tend to be quite conservative with the versions of a language that they choose, and I've heard rumors about memory corruption issues with 1.5 that will certainly scare away others, even if they are already fixed
@jdef @tsenart See Makefile for real change.