equivalent of godep go {build, run, install}

[thockin]

I'm stretching here, but you never get what you don't ask for.

godep supports the ability to wrap go commands and munge GOPATH. We're stuck using go-1.4 for some cases for a while yet. What if glide supported this? Something like:

glide wrap go build example.com/foo/bar

• make a tempdir
• symlink tempdir/src -> repo_of(example.com/foo/bar) + /vendor
• GOPATH=$GOPATH:tempdir
• go build example.com/foo/bar

[mattfarina]

If there was a restore function, like we're talking about on #366, would this be needed?

[thockin]

Some people want dedicated per-project GOPATH and some share. For people
who share, restore is a bad answer. If it is fast enough, it might be
OK, but we have a lot of Makefiles that do godep go build (discovered as
we try to change over to glide)

On Tue, Apr 5, 2016 at 12:38 PM, Matt Farina [email protected]
wrote:

If there was a restore function, like we're talking about on #366
#366, would this be needed?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#374 (comment)

[sdboyer]

speed might be the easiest option here. it's also the one i'd prefer, if we can get folks to accept it. the alternative adds potentially a fair bit of complexity...or at the very least, filesystem detritus. i haven't thought through whether what you're saying there actually would work, but assuming it does - it's the same sort of brittleness that's cursed previous tools. people might be used to that, but that doesn't mean it's a good pattern to replicate.

this is the kind of thing where i think good (read: fast, in this case) tooling should be able to render 'personal preferences' moot.

[mattfarina]

@thockin I want per-project GOPATH. Prior to the GO15VENDOREXPERIMENT we tried to do this on Glide and I've spoken with Dave Cheney about it for GB. There are a number of hard coded things in the go toolchain or the official add-ons that are brittle when you try to do per-project GOPATHs. We ran into a bunch of those.

There are a couple routes if you want to go there. First, you can rewrite parts of the go toolchain like GB is doing. Second, you can fake a proper environment with lots of copying. The latter is a bit slow due to all the copying. I've experimented with cross platform copying (I actually used k8s as an example to get big project support) and it's a bit of work to make it fast cross-platform.

When the vendor experiment came along we decided to try that and it's better than nothing if we want to use the core go toolchain.

Godep for go 1.4 is able to munge the GOPATH because of the Godeps/_workspace/src directory. A second directory in the GOPATH can be pointed to the _workspace directory and it mostly works. This is how Glide worked for go 1.4. It had the dependencies in the _vendor/src directory.

So, we've put a lot of thought into it.

How long do you need to support Go 1.4 for? I wonder if it's worth trying to create a go14 compatibility plugin for the short term.

[mattfarina]

Also, if anyone wants to talk per-project workspaces I'm game. It's not a small simple topic though.

[thockin]

We'll be supporting go-1.4 for at least another go release or two, I
suspect.

On Tue, Apr 5, 2016 at 2:07 PM, Matt Farina [email protected]
wrote:

Also, if anyone wants to talk per-project workspaces I'm game. It's not a
small simple topic though.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#374 (comment)

[mattfarina]

@thockin I was just looking at the Go release support cycle. The Go team isn't supporting 1.4, even for security issues, any longer. Is there anything detailing why Kubernetes is supporting Go versions the Go team is no longer supporting? Trying to wrap my head around this.

[thockin]

I rescind this request. We're going to press ahead, I think. Go 1.5 and 1.6 are measurably slower on several of our tests, but we're making progress.

[mattfarina]

@thockin if there a place to look (e.g., a SIG) to work on the Go 1.5 and 1.6 slowness. I may have someone I can point at that (in a week or so) who has performance skills.

[thockin]

We are getting help on this. One of the perks of working at Google is that
I can pretty literally call the core Go team and ask for help :) They are
keenly interested in the problem.

On Wed, Apr 13, 2016 at 9:34 AM, Matt Farina [email protected]
wrote:

@thockin https://github.com/thockin if there a place to look (e.g., a
SIG) to work on the Go 1.5 and 1.6 slowness. I may have someone I can point
at that (in a week or so) who has performance skills.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#374 (comment)