4 ms·

I really like the OP's structure and makefile, but it looks like a pain to work against Golang's grain here, even though the methodology makes a lot more sense

I really like the OP's structure and makefile, but it looks like a pain to work against Golang's grain here, even though the methodology makes a lot more sense to me. Maybe I have misunderstood the documentation, but what I truly, truly don't get about Go's $GOPATH is that it wants (1) my project directory to have some kind of canonical path, and (2) to pollute my project directory with dependencies. I have done a bunch of Go development and I still don't get it. So for example, I have myproject, which I naturally want to organize in this way: $HOME Projects foo .git src main.go stuff.go assets photo.png something.xml scripts setup_database.sh config config.sample.json Dockerfile Makefile Go wants me to throw this away and structure it like this: $HOME go bin [...] src github.com BurntSushi toml [...] zenazn goji [...] myaccount myproject .git main.go stuff.go assets photo.png something.xml scripts setup_database.sh config config.sample.json Dockerfile Makefile I'm supposed to work within this jungle of dependencies and generated files, in the middle of which sits my project. At least Java, for all its many faults, has the good sense to let you store dependencies nested as JAR files in a subfolder, as opposed to turning your own project into a dependency. I have tried fixing this by symlinking my project into $GOPATH/src/whatever, but Go doesn't let me to run "go" commands on things outside the $GOPATH, which makes this rather painful to do in a shell. Adding to the general confusion, Go doesn't manage canonical package paths, so github.com/zenazn/goji/main.go is in the package "goji" and github.com/zenazn/goji/graceful/[asterisk].go are in the package "graceful", but those package names only mean something to the importer. When "goji" wants to use the package "graceful", it imports "github.com/zenazn/goji/graceful", which, being a full URL, must be resolved from a root folder in GOPATH/src. At least Java (for all its... etc.) had the good sense to make dotted package names mirror the folder structure of a project, not URL, thus being internally consistent. Go wants everything to live in the same sea of things. Vendoring is just half the problem.

wallyhs 12y ago
Instead of throwing away your project structure, try creating a "go" subdirectory in your project and setting GOPATH to point to it. Yes, you need a separate GOPATH for each project, but it's no worse than needing a separate Python virtualenv for each project.
- lobster_johnson 12y ago
  That's what I'm doing these days. But it's painful. It means I have to run full commands such as "go install <my package>" or "go get <some package>". To install all dependencies, I have to do "go get <my package>". If I want to work on a project that depends on other projects that haven't been pushed to master yet, I have to clone those projects and symlink them in manually. It's pretty painful. Working with certain tools that assume a certain directory structure (protoc, for example, which computes paths relative to your Go root) is also painful. "go build ." does work. "No worse than virtualenv" isn't exactly a rousing endorsement. It's one of the poorer package-management systems out there. Go should be as simple and easy as Bundler. There's no excuse these days, I think.
  - wallyhs 12y ago
    You omitted that from your comment, but I agree. I was just pointing out the option, because it didn't sound as if you had tried it. I did not mean to endorse anything.
    - lobster_johnson 12y ago
      Yeah, sorry. I have been trying different things. Not happy. But at least it seems that I'm not alone in being dissatisfied. It's surprising because Go does a lot of things right, and disappointing because it's such a brake on productivity.
noedig 12y ago
I agree with your sentiments about Java. I wish I could just have my GOPATH contain 1) the source directory for my project, and 2) one or more directories with versioned Go source tarballs for my dependencies (gar files?).

wallyhs 12y ago

Instead of throwing away your project structure, try creating a "go" subdirectory in your project and setting GOPATH to point to it. Yes, you need a separate GOPATH for each project, but it's no worse than needing a separate Python virtualenv for each project.

lobster_johnson 12y ago
That's what I'm doing these days. But it's painful. It means I have to run full commands such as "go install <my package>" or "go get <some package>". To install all dependencies, I have to do "go get <my package>". If I want to work on a project that depends on other projects that haven't been pushed to master yet, I have to clone those projects and symlink them in manually. It's pretty painful. Working with certain tools that assume a certain directory structure (protoc, for example, which computes paths relative to your Go root) is also painful. "go build ." does work. "No worse than virtualenv" isn't exactly a rousing endorsement. It's one of the poorer package-management systems out there. Go should be as simple and easy as Bundler. There's no excuse these days, I think.
- wallyhs 12y ago
  You omitted that from your comment, but I agree. I was just pointing out the option, because it didn't sound as if you had tried it. I did not mean to endorse anything.
  - lobster_johnson 12y ago
    Yeah, sorry. I have been trying different things. Not happy. But at least it seems that I'm not alone in being dissatisfied. It's surprising because Go does a lot of things right, and disappointing because it's such a brake on productivity.

noedig 12y ago

I agree with your sentiments about Java. I wish I could just have my GOPATH contain 1) the source directory for my project, and 2) one or more directories with versioned Go source tarballs for my dependencies (gar files?).