5 ms·

That's what sucks though. I don't want a "gocode" folder and a "code" folder. It also doesn't fit very well in a monorepo with mixed languages. We had a small

That's what sucks though. I don't want a "gocode" folder and a "code" folder. It also doesn't fit very well in a monorepo with mixed languages. We had a small benchmark tool written in Go. And people simply couldn't build it, they always came to me after banging their head trying. This is basically what all of them did: $ cd <folder with all their projects and code> $ git clone <repo> $ cd <repo> $ go build And obviously it failed because it wasn't in a "src" folder (it was in a git, projects or code folder) nor had the $GOPATH environment variable set. But worst was probably the missing import path structure, i.e. "github.com/<company>/<repo>" that people simply just didn't get. They just want to clone anywhere and run "go build".

mseepgood 10y ago
> But worst was probably the missing import path structure, i.e. "github.com/<company>/<repo>" that people simply just didn't get. You obviously didn't vendor your dependencies in your project's vendor directory.
- bigdubs 10y ago
  Vendoring doesn't work outside $GOPATH
  - icholy 10y ago
    Why is this the case?
  - mixedCase 10y ago
    Don't work outside $GOPATH. Set a temporary one if you want a completely isolated environment for one-off building purposes.
    - stouset 10y ago
      Then what's even the point in the first place?
      - mixedCase 10y ago
        Development. Which is why I said "for one-off builds".
- Spiritus 10y ago
  It didn't have any external dependencies, only multiple packages.
- CannisterFlux 10y ago
  I found vendor directories to be documented in a confusing way, so I'm not surprised. https://golang.org/cmd/go/#hdr-Vendor_Directories https://golang.org/cmd/go/#hdr-Vendor_Directories I think the example there is hard to follow. Perhaps with more standard package names, such as golang.org/x/net or a popular github.com package, instead of the made up foo, baz, quux and so on it would be easier to understand exactly what advantages vendoring gives you.
- 0xdeadbeefbabe 10y ago
  If you choose to vendor part of stdlib like http then boom diamond dependency problem approaches.
- twblalock 10y ago
  > You obviously didn't vendor your dependencies in your project's vendor directory. You shouldn't have to! A good dependency management system will produce reproducible builds via dependency versioning without any need to "vendor" anything.
- fpoling 10y ago
  Even if one vendors the external dependencies, the code that uses them must still be on GOPATH or the compiler would not find them. This is at least with go 1.6.
thewhitetulip 10y ago
I agree on the point where it doesn't work well with mix languages. we can, however use `go get` rather than manually doing a git clone. I understand it'd be a pain to have Go setup, but once it is setup, it is great, When I write Go programs I do `$ cd /go/src/github.com/thewhitetulip/Tasks` `$ Tasks go build -o tasks` `$ Tasks ./tasks`
- stouset 10y ago
  How is this different from any other language where you "just" run `cd path/to/project; (make || rake || pants || cargo)`? This isn't special, and it's not something the go workspace makes possible.
  - thewhitetulip 10y ago
    This is different because $GOPATH is a requirement of the language and in _other_ languages, you have to manually clone the repos in the correct root folder which you store all your code into. Go allows you to do a go get reponame and it'll do the git clone stuff for you. that is nothing short of amazing as far as code management is concerned. I love it.
mappu 10y ago
Consider checking in the whole gopath to the VCS, and supply a makefile that calls `GOPATH=$(pwd) go build`. You see this for Java projects where the whole source code is nested half a dozen folders deep (src/com/foo/bar/baz/myproject/...) so i don't think it's unfamiliar.
- stouset 10y ago
  Yes, there are silly workarounds. The whole point is that it's a PITA to work with and breaks many common workflows for scant few actual benefits. Especially now that `godep` is in wide use, which just artificially creates the go workspace structure from in-tree dependencies anyway.
- IshKebab 10y ago
  What if I don't use Makefiles, because I live in the 21st century?
  - tartley 10y ago
    That's like saying "I don't use wheels, because I don't live in the prehistoric era when they were invented." Some tools are fundamental. A tool to solve the problem of executing dependant tasks is one of them. Solutions to these fundamental problems tend to be implemented early on. Some of those early solutions were poor, and have fallen out of use. Some of them were good, and have been refined in the intervening years, and hence are still with us. A good tool to solve a fundamental problem is still useful, no matter how old it is.
  - icedchai 10y ago
    You could make a shell script instead.
travisby 10y ago
Take a look at [gvm](https://github.com/moovweb/gvm https://github.com/moovweb/gvm) I create (similar to a python virtualenv) a pkgset, and then use `linkthis` to link my current directory as a certain path in my gopath. You could do it yourself with symlinks, but I've been loving the tool for other things it provides, too (like easy access to new versions). You can feel free to have any repo path you want :D
IshKebab 10y ago
I agree. I think the real problem is that they are using environment variables for this. Environment variables just aren't user friendly, especially on Windows. It would be better if Go just downloaded all `go get` packages to some default fixed directory (%appdata%/go or whatever), and then the code the people manually download/write could live anywhere.
thewhitetulip 10y ago
On another note, I suggest you work around this limitation, you can write a benchmark in Go in the $GOPATH of your company or anything and then use `go install` to install it to the $PATH of your machine, so you can call the benchmark directly. This will separate the codebases. Otherwise you can write the other language code in the $GOPATH itself.

mseepgood 10y ago

> But worst was probably the missing import path structure, i.e. "github.com/<company>/<repo>" that people simply just didn't get. You obviously didn't vendor your dependencies in your project's vendor directory.

bigdubs 10y ago
Vendoring doesn't work outside $GOPATH
- icholy 10y ago
  Why is this the case?
- mixedCase 10y ago
  Don't work outside $GOPATH. Set a temporary one if you want a completely isolated environment for one-off building purposes.
  - stouset 10y ago
    Then what's even the point in the first place?
    - mixedCase 10y ago
      Development. Which is why I said "for one-off builds".
Spiritus 10y ago
It didn't have any external dependencies, only multiple packages.
CannisterFlux 10y ago
I found vendor directories to be documented in a confusing way, so I'm not surprised. https://golang.org/cmd/go/#hdr-Vendor_Directories https://golang.org/cmd/go/#hdr-Vendor_Directories I think the example there is hard to follow. Perhaps with more standard package names, such as golang.org/x/net or a popular github.com package, instead of the made up foo, baz, quux and so on it would be easier to understand exactly what advantages vendoring gives you.
0xdeadbeefbabe 10y ago
If you choose to vendor part of stdlib like http then boom diamond dependency problem approaches.
twblalock 10y ago
> You obviously didn't vendor your dependencies in your project's vendor directory. You shouldn't have to! A good dependency management system will produce reproducible builds via dependency versioning without any need to "vendor" anything.
fpoling 10y ago
Even if one vendors the external dependencies, the code that uses them must still be on GOPATH or the compiler would not find them. This is at least with go 1.6.

thewhitetulip 10y ago

I agree on the point where it doesn't work well with mix languages. we can, however use `go get` rather than manually doing a git clone. I understand it'd be a pain to have Go setup, but once it is setup, it is great, When I write Go programs I do `$ cd /go/src/github.com/thewhitetulip/Tasks` `$ Tasks go build -o tasks` `$ Tasks ./tasks`

stouset 10y ago
How is this different from any other language where you "just" run `cd path/to/project; (make || rake || pants || cargo)`? This isn't special, and it's not something the go workspace makes possible.
- thewhitetulip 10y ago
  This is different because $GOPATH is a requirement of the language and in _other_ languages, you have to manually clone the repos in the correct root folder which you store all your code into. Go allows you to do a go get reponame and it'll do the git clone stuff for you. that is nothing short of amazing as far as code management is concerned. I love it.

mappu 10y ago

Consider checking in the whole gopath to the VCS, and supply a makefile that calls `GOPATH=$(pwd) go build`. You see this for Java projects where the whole source code is nested half a dozen folders deep (src/com/foo/bar/baz/myproject/...) so i don't think it's unfamiliar.

stouset 10y ago
Yes, there are silly workarounds. The whole point is that it's a PITA to work with and breaks many common workflows for scant few actual benefits. Especially now that `godep` is in wide use, which just artificially creates the go workspace structure from in-tree dependencies anyway.
IshKebab 10y ago
What if I don't use Makefiles, because I live in the 21st century?
- tartley 10y ago
  That's like saying "I don't use wheels, because I don't live in the prehistoric era when they were invented." Some tools are fundamental. A tool to solve the problem of executing dependant tasks is one of them. Solutions to these fundamental problems tend to be implemented early on. Some of those early solutions were poor, and have fallen out of use. Some of them were good, and have been refined in the intervening years, and hence are still with us. A good tool to solve a fundamental problem is still useful, no matter how old it is.
- icedchai 10y ago
  You could make a shell script instead.

travisby 10y ago

Take a look at [gvm](https://github.com/moovweb/gvm https://github.com/moovweb/gvm) I create (similar to a python virtualenv) a pkgset, and then use `linkthis` to link my current directory as a certain path in my gopath. You could do it yourself with symlinks, but I've been loving the tool for other things it provides, too (like easy access to new versions). You can feel free to have any repo path you want :D

IshKebab 10y ago

I agree. I think the real problem is that they are using environment variables for this. Environment variables just aren't user friendly, especially on Windows. It would be better if Go just downloaded all `go get` packages to some default fixed directory (%appdata%/go or whatever), and then the code the people manually download/write could live anywhere.

thewhitetulip 10y ago

On another note, I suggest you work around this limitation, you can write a benchmark in Go in the $GOPATH of your company or anything and then use `go install` to install it to the $PATH of your machine, so you can call the benchmark directly. This will separate the codebases. Otherwise you can write the other language code in the $GOPATH itself.