Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

equivalent of godep go {build, run, install} #374

Closed
thockin opened this issue Apr 5, 2016 · 10 comments
Closed

equivalent of godep go {build, run, install} #374

thockin opened this issue Apr 5, 2016 · 10 comments

Comments

@thockin
Copy link
Contributor

thockin commented Apr 5, 2016

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
Copy link
Member

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

@thockin
Copy link
Contributor Author

thockin commented Apr 5, 2016

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 notifications@github.com
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
Copy link
Member

sdboyer commented Apr 5, 2016

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
Copy link
Member

@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
Copy link
Member

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

@thockin
Copy link
Contributor Author

thockin commented Apr 6, 2016

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 notifications@github.com
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
Copy link
Member

@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
Copy link
Contributor Author

thockin commented Apr 12, 2016

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.

@thockin thockin closed this as completed Apr 12, 2016
@mattfarina
Copy link
Member

@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
Copy link
Contributor Author

thockin commented Apr 13, 2016

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 notifications@github.com
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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants