3 ms·

What do GOPATH, the project folder structure, package management, and package versioning all have in common? The go command. Not the linker, not the compiler -

What do GOPATH, the project folder structure, package management, and package versioning all have in common? The go command. Not the linker, not the compiler -- the `make` replacement. If you want to fix the most broken parts of Go -- its ecosystem management tooling -- just replace your `go` command. I have, and I love working on a project with a proper top-level src folder, with vendor-able packages discoverable in a top-level lib folder pinned to known-good commits. There are literally dozens of go replacements, but the winning combination for me is using Goop [1], Makefiles, and symlinks to subvert `go get` and the naive way it parses import declarations [2]. [1] https://github.com/nitrous-io/goop https://github.com/nitrous-io/goop [2] https://golang.org/ref/spec#Import_declarations https://golang.org/ref/spec#Import_declarations

NateDad 12y ago
You don't have to replace the go command to do that. The only thing that needs the GOPATH and expects import paths to be URLs is "go get". You can very easily make a go project that uses all relative import paths and put it anywhere you like. Dependencies then just get copied into whatever path you like using whatever name you like. However, your code will be unusable by anyone who follows the normal Go way of coding, so you'll be missing out on working with the rest of the community. If you're writing proprietary software, that might not matter too much. But if you're writing open source code, it will be a huge hindrance to getting contributions from outsiders.
- politician 12y ago
  > However, your code will be unusable by anyone who follows the normal Go way of coding. Well, that's not really true given the major projects using tools like Godeps [1], so while that argument certainly sounds good, it doesn't actually seem to be a problem in practice. [1] https://coreos.com/blog/godep-for-end-user-go-projects/ https://coreos.com/blog/godep-for-end-user-go-projects/
  - NateDad 12y ago
    Actually, CoreOS is using the version of godep that rewrites import paths, so that most developers can use "go get". The only time you need to use godep is when you're updating one of the vendored dependencies. That's actually the awesome thing about godep - it keeps your repo go-getable. > the simplicity it presents to regular contributors and users used to go get make it worth the additional effort

NateDad 12y ago

You don't have to replace the go command to do that. The only thing that needs the GOPATH and expects import paths to be URLs is "go get". You can very easily make a go project that uses all relative import paths and put it anywhere you like. Dependencies then just get copied into whatever path you like using whatever name you like. However, your code will be unusable by anyone who follows the normal Go way of coding, so you'll be missing out on working with the rest of the community. If you're writing proprietary software, that might not matter too much. But if you're writing open source code, it will be a huge hindrance to getting contributions from outsiders.

politician 12y ago
> However, your code will be unusable by anyone who follows the normal Go way of coding. Well, that's not really true given the major projects using tools like Godeps [1], so while that argument certainly sounds good, it doesn't actually seem to be a problem in practice. [1] https://coreos.com/blog/godep-for-end-user-go-projects/ https://coreos.com/blog/godep-for-end-user-go-projects/
- NateDad 12y ago
  Actually, CoreOS is using the version of godep that rewrites import paths, so that most developers can use "go get". The only time you need to use godep is when you're updating one of the vendored dependencies. That's actually the awesome thing about godep - it keeps your repo go-getable. > the simplicity it presents to regular contributors and users used to go get make it worth the additional effort