Thanks for Your suggestions so far. I will have to do further tests to see what suits our team best.
Regards, Boris Am Di., 11. Juni 2019 um 23:47 Uhr schrieb David Riley <fraveyd...@gmail.com >: > On Jun 11, 2019, at 13:38, Ronny Bangsund <ronny.bangs...@gmail.com> > wrote: > > > > On Tuesday, June 11, 2019 at 2:47:44 PM UTC+2, Boris Mühmer wrote: >> >> Is the project layout total rubbish? >> > > I'm not sure - all I know is that it's different from how I prefer it, and > "pkg" is the one thing I frequently see people dislike ;) > If you want to share packages, parent them to the project directory. > Anything you feel is too niche you can hide inside internal/. Binaries in > cmd/ makes it nice and tidy, but you can get away with top-level main > packages if there's only one command and it's really simple (few source > files to clutter it up). > > > This layout is, I feel, most useful for large projects which build many > binaries and have many packages (which is what we use it for). In that > context, it’s great. > > I might make a server cmd the same name as the project directory, and if > possible, make it have CLI options to control itself (talk via local > socket, gRPC, REST, whatever). Pleasing VS Code is mainly about configuring > the build task(s). I like to have Release and Debug tasks, sometimes with > tasks requiring other tasks (client-server projects, for instance). > > > One thing I’ve found it doesn’t work especially nicely with is things that > have files hardcoded to be in `pwd` (the common “task” utility is an > example of this), because then you get your nice, tidy top level cluttered > with dreck from your tools. > > Also, `go test` runs its commands from the directory of the tested > package, not the current working directory, but that gripe is better hashed > out elsewhere. > > I haven't looked closely at the current state of modules to say anything > about how it'll change up my standards, but it looks like we're expected to > run module stuff out of the top-level directory. If not, aren't those parts > better off breaking out into their own standalone projects? Running module > setup in sub-directories with potentially different versions of external > dependencies feels dirty. > > > It works fine with modules, at least assuming your repo directory is one > module! We haven’t tried it with sub-modules, mostly because that feels > like madness. > > > - Dave > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/174A6172-8A4B-47F0-9C49-F54A7D1B17A8%40gmail.com > <https://groups.google.com/d/msgid/golang-nuts/174A6172-8A4B-47F0-9C49-F54A7D1B17A8%40gmail.com?utm_medium=email&utm_source=footer> > . > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CALW2tjrL8bDJvqh3cZGMhK6GNoy7XNJhKFwmhFW9FJqH92KtqQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
