3 ms·
Heh, I was wondering that myself, but I try not to get too hungup on votes :) Per project is just going to be a pain in the butt, honestly. It means you'll ne
by NateDad 13y ago
Heh, I was wondering that myself, but I try not to get too hungup on votes :)
Per project is just going to be a pain in the butt, honestly. It means you'll need to constantly swap out the gopath, and there's really very little harm in having all your go code in one giant gopath. The only time it is a problem is if you use different branches of a package for different projects. That has been very rare in my experience, hopefully it will be in yours as well.
However, I do know some people that have a gopath per project... you certainly can do it, it's just more work. But what you do need is some sort of gopath. It's fundamental to the language. In theory you could probably build without one if all your imports were relative, and you checked out code without go get... but you'd end up with non-idiomatic go code that no one else would touch with a ten foot pole, and you'd lose a lot of the cohesiveness of the tooling.