3 ms·

I think Go works very well without Makefiles. (IMHO even better) You can just enter `go build .` You can install the stuff using your favorite package manager,

I think Go works very well without Makefiles. (IMHO even better) You can just enter `go build .` You can install the stuff using your favorite package manager, e.g. dpkg - then it's even possible to uninstall your stuff.

misnome 10y ago
Then why is this necessary - why isn't it just: all: go build
- Sphax 10y ago
  All this is necessary because people don't expect or don't want to put their code/projects under $GOPATH/src. My take on it is don't fight the GOPATH, because a lot of Go tooling expects your code to be in a valid GOPATH.
  - Anderkent 10y ago
    This is one of the main reasons I hate working with go projects. I have about 50 different git repos checked out on my machine right now; written in different languages. Over they years I've worked out a structure for these repos that helps me keep track of what's where and switch between them easily. But then go comes along and is like 'no, you MUST check this out in this particular location'. And also that location has to be 6 directory layers deep, for some reason. It's just pointlessly broken when compared to every other language, where a project is self-contained within a directory.
    - blablabla123 10y ago
      Ok but when you hate them, why do you check them out manually? You can just mkdir $GOPATH ; go get { pkg1, pkg2, ..., pkg50 } I mean, nobody complains that npm -g puts stuff into some weird node directory that you should never ever touch manually. Or did you ever compile a random Java project that doesn't use Maven? I think regarding convenience Go is top notch. Regarding "weirdness" it's in the middle between Unix C and Java.
      - Anderkent 10y ago
        > Ok but when you hate them, why do you check them out manually? You can just mkdir $GOPATH ; go get { pkg1, pkg2, ..., pkg50 } That still has the same issue of all my projects following a logical structure, except for anything written in go / with a component written in go, which has at $RANDOM_LOCATION. Plus, I think `go get` doesn't work with our internal company git server, but I'm not 100% about it.
        blablabla123 10y ago
        >That still has the same issue of all my projects following a logical structure, except for anything written in go / with a component >written in go, which has at $RANDOM_LOCATION. Wellll... if you are not reeeally using Go but only for short snippets or smaller projects you can place the code anywhere you like. (Except for the external deps afaik, but even that might work with ./vendors/) In your imports you need to then use relative paths. Haven't used this coding style since some time but you can totally do that. Of course you loose some goodies like having super isolated modules but it sounds you're not after that anyway. Disclaimer: I've used this coding style for a few 1 kLoC+ projects, but I later changed to the recommended way. >Plus, I think `go get` doesn't work with our internal company git server, but I'm not 100% about it. You can still manually git/hg/... clone but yeah...
ctz 10y ago
Thanks. Now I get a console full of: thing.go:10:2: cannot find package "whatever/thing/frob" in any of: /usr/lib/go-1.7/src/whatever/thing/frob (from $GOROOT) ($GOPATH not set) So I go looking for GOPATH documentation, and it tells me I need to put all my source dependencies in one directory. That's unlike everything else on the planet, but OK. I do that, and set GOPATH=~/go. Now: thing.go:10:2: cannot find package "whatever/thing/frob" in any of: /usr/lib/go-1.7/src/whatever/thing/frob (from $GOROOT) /home/ctz/go/src/whatever/thing/frob (from $GOROOT) ($GOPATH not set) OK, so do I need to set GOPATH as well? thing.go:4:2: cannot find package "bytes" in any of: /home/ctz/go/src/bytes (from $GOROOT) ($GOPATH not set) thing.go:8:2: cannot find package "container/list" in any of: /home/ctz/go/src/container/list (from $GOROOT) ($GOPATH not set) That seems worse. Now somebody teaches me about 'go get'. Great! package whatever/thing/frob: unrecognized import path "whatever/thing/frob" (import path does not begin with hostname) (To be clear, I now can build all the golang code I want. This post is more indicative of my experience getting started a few years ago. In my opinion, GOPATH is a terrible design decision.)
- blablabla123 10y ago
  You can check in your dependencies into vendors/, in case they are so complex. However it's recommended to only have few dependencies. Yes, you need to install your deps separately. (If the maintainer decides not to use vendors/ and not check it into git) With C, the classic ./configure && make && make install also expects you to install your dependencies manually. Using Go you have a canonical way to do it. Also if you don't plan to hack on it, it's probably a got idea to go with binary packages. If there are none, the tool is probably not exactly meant for production anyway.

misnome 10y ago

Then why is this necessary - why isn't it just: all: go build

Sphax 10y ago
All this is necessary because people don't expect or don't want to put their code/projects under $GOPATH/src. My take on it is don't fight the GOPATH, because a lot of Go tooling expects your code to be in a valid GOPATH.
- Anderkent 10y ago
  This is one of the main reasons I hate working with go projects. I have about 50 different git repos checked out on my machine right now; written in different languages. Over they years I've worked out a structure for these repos that helps me keep track of what's where and switch between them easily. But then go comes along and is like 'no, you MUST check this out in this particular location'. And also that location has to be 6 directory layers deep, for some reason. It's just pointlessly broken when compared to every other language, where a project is self-contained within a directory.
  - blablabla123 10y ago
    Ok but when you hate them, why do you check them out manually? You can just mkdir $GOPATH ; go get { pkg1, pkg2, ..., pkg50 } I mean, nobody complains that npm -g puts stuff into some weird node directory that you should never ever touch manually. Or did you ever compile a random Java project that doesn't use Maven? I think regarding convenience Go is top notch. Regarding "weirdness" it's in the middle between Unix C and Java.
    - Anderkent 10y ago
      > Ok but when you hate them, why do you check them out manually? You can just mkdir $GOPATH ; go get { pkg1, pkg2, ..., pkg50 } That still has the same issue of all my projects following a logical structure, except for anything written in go / with a component written in go, which has at $RANDOM_LOCATION. Plus, I think `go get` doesn't work with our internal company git server, but I'm not 100% about it.
      - blablabla123 10y ago
        >That still has the same issue of all my projects following a logical structure, except for anything written in go / with a component >written in go, which has at $RANDOM_LOCATION. Wellll... if you are not reeeally using Go but only for short snippets or smaller projects you can place the code anywhere you like. (Except for the external deps afaik, but even that might work with ./vendors/) In your imports you need to then use relative paths. Haven't used this coding style since some time but you can totally do that. Of course you loose some goodies like having super isolated modules but it sounds you're not after that anyway. Disclaimer: I've used this coding style for a few 1 kLoC+ projects, but I later changed to the recommended way. >Plus, I think `go get` doesn't work with our internal company git server, but I'm not 100% about it. You can still manually git/hg/... clone but yeah...

ctz 10y ago

Thanks. Now I get a console full of: thing.go:10:2: cannot find package "whatever/thing/frob" in any of: /usr/lib/go-1.7/src/whatever/thing/frob (from $GOROOT) ($GOPATH not set) So I go looking for GOPATH documentation, and it tells me I need to put all my source dependencies in one directory. That's unlike everything else on the planet, but OK. I do that, and set GOPATH=~/go. Now: thing.go:10:2: cannot find package "whatever/thing/frob" in any of: /usr/lib/go-1.7/src/whatever/thing/frob (from $GOROOT) /home/ctz/go/src/whatever/thing/frob (from $GOROOT) ($GOPATH not set) OK, so do I need to set GOPATH as well? thing.go:4:2: cannot find package "bytes" in any of: /home/ctz/go/src/bytes (from $GOROOT) ($GOPATH not set) thing.go:8:2: cannot find package "container/list" in any of: /home/ctz/go/src/container/list (from $GOROOT) ($GOPATH not set) That seems worse. Now somebody teaches me about 'go get'. Great! package whatever/thing/frob: unrecognized import path "whatever/thing/frob" (import path does not begin with hostname) (To be clear, I now can build all the golang code I want. This post is more indicative of my experience getting started a few years ago. In my opinion, GOPATH is a terrible design decision.)

blablabla123 10y ago
You can check in your dependencies into vendors/, in case they are so complex. However it's recommended to only have few dependencies. Yes, you need to install your deps separately. (If the maintainer decides not to use vendors/ and not check it into git) With C, the classic ./configure && make && make install also expects you to install your dependencies manually. Using Go you have a canonical way to do it. Also if you don't plan to hack on it, it's probably a got idea to go with binary packages. If there are none, the tool is probably not exactly meant for production anyway.