3 ms·
This is what I've ended up doing, and it still drives me absolutely batty. Typically I'd group together all of the code and assets for a project in one place; a
by matthewmacleod 10y ago
This is what I've ended up doing, and it still drives me absolutely batty. Typically I'd group together all of the code and assets for a project in one place; any Go code has to exist in this separate namespace for no convincing reason.
It's fine, I can work around it, but it's still quite annoying.
- ptero 10y agoI think I am in the same boat -- Go file layout model seems to be for multiple projects written in Go instead of (my typical case) a multi-language project with a component in Go. It is not really a big deal, I can overcome it with some simlinks and conventions, but this is not elegant; I hope a model to support this better will be added sometime.
- coldtea 10y ago>any Go code has to exist in this separate namespace for no convincing reason. The convincing reason is that you get several automated behaviors in fetching, installing and building this way. If you don't care for those, you can use whatever path you like for your code, and a custom makefile for building. Just don't expect "go build", "go install" etc to work.
- hazbo 10y agoSomething I pretty much do and have heard from other Go people that they do this also, is to just keep all my projects in the GOPATH. Whether they be written in Go or not. It essentially gives you an organised structure based on git URLs, so it's always easy to find anything. I use $HOME/go, and have projects in there written in a bunch of languages.
- woah 10y agoI do this. It's actually a pretty good way to organize code in general, not just Go. Still dumb that they force it on you.