4 ms·

Yeah, this gets super annoying when you need your project written in other languages to contain go code. I worked on the YCM support for godef, we eventually h

Yeah, this gets super annoying when you need your project written in other languages to contain go code. I worked on the YCM support for godef, we eventually had to fork the library and rewrite paths since there was no way of pinning to a version within YCM. Libraries written with github paths for `go get` do not play nice with living outside of gopath, and libraries written with relative paths don't work with go get (even though this is something that go could support)

alexbecker 10y ago
I use a make rule which appends the local go directories to GOPATH before running "go _". Inelegant, but it works.
jerf 10y ago
I've got a couple of projects that contain Go code. The Go code does not need to be the top level of the project. I just either check it out into the gopath or symlink it in (usually the former since I've already set up CDPATH in bash to go to the directory the project is living in), and the import paths in my go code point at something like scm.localdomain.com/team/project/go, where the "project" directory is the top level directory for the project that has no Go code in it. This is even fully go getable if you "go get scm.localdomain.com/team/project/go/cmd/whatever" or something.
- Manishearth 10y ago
  YCM can't require its users to do that, nor can it pollute the gopath which may not be set when it is installed, nor can it rely on that path always being the same or the installed files not being removed. It's fine for a Go project, but this is not a Go project. It should not be forced to change how it works because it wants to contain some Go code.
  - mixedCase 10y ago
    >It should not be forced to change how it works because it wants to contain some Go code. Go is not like Python, the end result is a binary, not interpreted source code. You can simply write a build script that sets a custom GOPATH inside a temporary folder, pulls all dependencies, builds and pops out a binary ready for use; and you can either discard or save your custom GOPATH anywhere for caching purposes.
    - Manishearth 10y ago
      Fair. Note that this wasn't the only reason we had to fork. Go doesn't (or didn't) provide a way to pin to a dependency, so we would have had to fork anyway, and then rewrite all the paths anyway, so I went the way of using local paths in the fork.
      - mixedCase 10y ago
        You can probably consider unforking now that the vendor directory is a thing. I'm sure it'd be easier than rebasing on every update.

alexbecker 10y ago

I use a make rule which appends the local go directories to GOPATH before running "go _". Inelegant, but it works.

jerf 10y ago

I've got a couple of projects that contain Go code. The Go code does not need to be the top level of the project. I just either check it out into the gopath or symlink it in (usually the former since I've already set up CDPATH in bash to go to the directory the project is living in), and the import paths in my go code point at something like scm.localdomain.com/team/project/go, where the "project" directory is the top level directory for the project that has no Go code in it. This is even fully go getable if you "go get scm.localdomain.com/team/project/go/cmd/whatever" or something.

Manishearth 10y ago
YCM can't require its users to do that, nor can it pollute the gopath which may not be set when it is installed, nor can it rely on that path always being the same or the installed files not being removed. It's fine for a Go project, but this is not a Go project. It should not be forced to change how it works because it wants to contain some Go code.
- mixedCase 10y ago
  >It should not be forced to change how it works because it wants to contain some Go code. Go is not like Python, the end result is a binary, not interpreted source code. You can simply write a build script that sets a custom GOPATH inside a temporary folder, pulls all dependencies, builds and pops out a binary ready for use; and you can either discard or save your custom GOPATH anywhere for caching purposes.
  - Manishearth 10y ago
    Fair. Note that this wasn't the only reason we had to fork. Go doesn't (or didn't) provide a way to pin to a dependency, so we would have had to fork anyway, and then rewrite all the paths anyway, so I went the way of using local paths in the fork.
    - mixedCase 10y ago
      You can probably consider unforking now that the vendor directory is a thing. I'm sure it'd be easier than rebasing on every update.