For projects that are mostly not go (or go is a component anyway) you could do $HOME/project/src/<go code here> and then point $GOPATH=$HOME/project. You can use 2 different segments in $GOPATH (GOPATH=/foo/bar:/bar/foo) and go get will place go gettable packages in the first segment of $GOPATH.
On Thu, Sep 1, 2016 at 10:57 AM Maurizio Vitale <mrz....@gmail.com> wrote: > hello gophers, > > How people do use GOPATH? > > having a single workspace for all my projects doesn't really work for me. > Some project might involve more than a go portion and really shoehorning > them into a go tree doesn't sound right. > > I'm completely fine with switching GOPATH every time I switch project and > there's a benefit in having the complete environment in the same tree. but > how people handle internal include paths? the only thing I can think of is > symlinking from down into the project path so that you can import as if you > were from(say) github.com/user/project. > > And even if switching, there're certain things I want to 'go get' and > share across all projects. For instance godep and the such. I could switch > GOPATH, go get and then just add the bin directory to PATH. Is this what > people do? or do they have a complete set of tools per project (even this > is defendible and I'm not completely against it) > > please enlighten me, thanks > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
