4 ms·
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 s
by 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 agoFair. 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 agoYou can probably consider unforking now that the vendor directory is a thing. I'm sure it'd be easier than rebasing on every update.