4 ms·

For dependency management we use Dep (https://github.com/golang/dep https://github.com/golang/dep) combined with (https://github.com/getstream/vg https://github

For dependency management we use Dep (https://github.com/golang/dep https://github.com/golang/dep) combined with (https://github.com/getstream/vg https://github.com/getstream/vg). This works pretty well.

raziel2p 9y ago
I didn't know about vg and it looked promising, but I was disappointed to see that it still requires that I initialize all my projects in a subdirectory of $GOPATH/src. Why does go (and/or its tools) enforce this? Why can't I put my projects in ~/code? Why do I need a "github.com" subdirectory? Feels so silly.
- JelteF 9y ago
  Main developer of vg here. In principle vg should work for packages outside of GOPATH when using full isolation mode (which has its own set of problem, see README for details). Its dep integration doesn't work then though last time I tried. As far as I can tell the main reason why Go tooling needs GOPATH is because everything uses absolute imports and relative ones can translated to absolute ones by always working from inside the workspace. I've solved my main issue with GOPATH in a very easy way though. I just create symlinks in my normal directories (like ~/work) to my projects in GOPATH. This allows me to go to my own projects easily while still having everything in GOPATH.
  - collinvandyck76 9y ago
    I use zsh and there is an easy way to find your golang projects using cdpath: # setup easy access to cd paths setopt auto_cd cdpath=($HOME/code/go/src/github.com \ $HOME/code/go/src/github.com/collinvandyck \ $HOME/code \ $HOME/code/go/src)
- roganartu 9y ago
  There is a detailed explanation of how package names are used by the compiler here: https://golang.org/cmd/go/#hdr-Description_of_package_lists https://golang.org/cmd/go/#hdr-Description_of_package_lists Specifically this bit is relevant here: > Every package in a program must have a unique import path. By convention, this is arranged by starting each path with a unique prefix that belongs to you. For example, paths used internally at Google all begin with 'google', and paths denoting remote repositories begin with the path to the code, such as 'github.com/user/repo'. Most (all?) Go tooling assumes this convention. Conceptually, I don't see it as that different from how other languages determine input paths, except in Go they are guaranteed to be unique which I consider a good thing. In Java for example you still have file namespaces they're just inside the project itself (looking at you `src/java/com/example/package`) or Python which looks for the root module name in `PYTHONPATH` and then recurses down for submodule names. Most if not all languages use file structures to namespace imports in one way or another, Go just applies it globally instead of at a project level. I agree it raises the barrier to entry for someone to just come in and run `go run` on a project but I find it works very well once you've got it setup. Convention over configuration is a big thing in Go tooling.
rcarmo 9y ago
I found the article's stance on vendoring to be quite restrained. I can't wait until Dep becomes _the_ solution. That and getting rid of GOPATH (I work across multiple machines, and need to bootstrap new environments regularly).

raziel2p 9y ago

I didn't know about vg and it looked promising, but I was disappointed to see that it still requires that I initialize all my projects in a subdirectory of $GOPATH/src. Why does go (and/or its tools) enforce this? Why can't I put my projects in ~/code? Why do I need a "github.com" subdirectory? Feels so silly.

JelteF 9y ago
Main developer of vg here. In principle vg should work for packages outside of GOPATH when using full isolation mode (which has its own set of problem, see README for details). Its dep integration doesn't work then though last time I tried. As far as I can tell the main reason why Go tooling needs GOPATH is because everything uses absolute imports and relative ones can translated to absolute ones by always working from inside the workspace. I've solved my main issue with GOPATH in a very easy way though. I just create symlinks in my normal directories (like ~/work) to my projects in GOPATH. This allows me to go to my own projects easily while still having everything in GOPATH.
- collinvandyck76 9y ago
  I use zsh and there is an easy way to find your golang projects using cdpath: # setup easy access to cd paths setopt auto_cd cdpath=($HOME/code/go/src/github.com \ $HOME/code/go/src/github.com/collinvandyck \ $HOME/code \ $HOME/code/go/src)
roganartu 9y ago
There is a detailed explanation of how package names are used by the compiler here: https://golang.org/cmd/go/#hdr-Description_of_package_lists https://golang.org/cmd/go/#hdr-Description_of_package_lists Specifically this bit is relevant here: > Every package in a program must have a unique import path. By convention, this is arranged by starting each path with a unique prefix that belongs to you. For example, paths used internally at Google all begin with 'google', and paths denoting remote repositories begin with the path to the code, such as 'github.com/user/repo'. Most (all?) Go tooling assumes this convention. Conceptually, I don't see it as that different from how other languages determine input paths, except in Go they are guaranteed to be unique which I consider a good thing. In Java for example you still have file namespaces they're just inside the project itself (looking at you `src/java/com/example/package`) or Python which looks for the root module name in `PYTHONPATH` and then recurses down for submodule names. Most if not all languages use file structures to namespace imports in one way or another, Go just applies it globally instead of at a project level. I agree it raises the barrier to entry for someone to just come in and run `go run` on a project but I find it works very well once you've got it setup. Convention over configuration is a big thing in Go tooling.

rcarmo 9y ago

I found the article's stance on vendoring to be quite restrained. I can't wait until Dep becomes _the_ solution. That and getting rid of GOPATH (I work across multiple machines, and need to bootstrap new environments regularly).