4 ms·

> Ok but when you hate them, why do you check them out manually? You can just mkdir $GOPATH ; go get { pkg1, pkg2, ..., pkg50 } That still has the same issue o

> Ok but when you hate them, why do you check them out manually? You can just mkdir $GOPATH ; go get { pkg1, pkg2, ..., pkg50 } That still has the same issue of all my projects following a logical structure, except for anything written in go / with a component written in go, which has at $RANDOM_LOCATION. Plus, I think `go get` doesn't work with our internal company git server, but I'm not 100% about it.

blablabla123 10y ago
>That still has the same issue of all my projects following a logical structure, except for anything written in go / with a component >written in go, which has at $RANDOM_LOCATION. Wellll... if you are not reeeally using Go but only for short snippets or smaller projects you can place the code anywhere you like. (Except for the external deps afaik, but even that might work with ./vendors/) In your imports you need to then use relative paths. Haven't used this coding style since some time but you can totally do that. Of course you loose some goodies like having super isolated modules but it sounds you're not after that anyway. Disclaimer: I've used this coding style for a few 1 kLoC+ projects, but I later changed to the recommended way. >Plus, I think `go get` doesn't work with our internal company git server, but I'm not 100% about it. You can still manually git/hg/... clone but yeah...