
I'll Take Pkg over Internal - pythonist
https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/
======
0xFACEFEED
Love Go. But this is yet another case where language creators opted out of
standardizing something they should have. The community is left to fend for
themselves and squabble over naming conventions and boilerplate.

The golang-standards/project-layout repo is the inevitable outcome. An over-
engineered land grab (let's call it what it is). But 11k stars is a decent
indicator of Go programmers wanting some kind of authoritative standard so
they don't need to re-organize their now-small but tomorrow-large projects
over and over.

A recent issue that parallels this one is package management. So many
monstrosities came out of that until go modules was formalized :P

------
enneff
My advice is to not overthink it and do what works for you.

IMO,

don’t use a pkg directory. It only makes your import paths more unwieldy.

Don’t use internal unless you have a package that is an awkward implementation
detail that must be shared between packages for expedience. Usually this can
be factored away with some effort but sometimes it’s not worth it.

Do use cmd directories. They make it clear what “go install” will do.

But otherwise really just pick any approach and move on with your life.

~~~
travisjeffery
First of all I think it's cool enneff read my post.

But pkg doesn't only make your import paths unwiedy. I'ts more like that's the
only---or at least main---issue with pkg. But you get benefits from it that I
talked about: consistent layout structure; know what directories are packages;
separate your packages from examples, docs, etc. If pkg only made your import
paths unwiedy then no one would use it.

------
dmlittle
I like the use of pkg/ as it allows you to separate your source code from
other things that might be in the repository such as a README, LICENSE,
Dockerfile, Makefile, linter configurations, go version configuration, etc.
These things usually live in the root of the repository so you know to look
for them there but if you also have your source code there it makes things
harder to find.

This is also one of the reasons why some other programming languages might
have adopted the standard of src/ or lib/.

------
blaisio
> Most people who would bother with the matter at all would admit that the
> layout of Go projects is in a bad way.

... How? They just don't tell you that files have to be under a certain
directory. It's beyond me how that upsets people.

I think this is just people looking for something to argue about. The go team
can't standardize _everything_.

~~~
travisjeffery
Most popular languages do, it seems reasonable.

------
Insanity
Somehow the text was hard to read / follow for me. Might be because I'm a bit
tired though.

Anyway, OT: Even though there might not be an "official" standard, there is
indeed a community standard.

If I explore other projects I hope to see some common structures reflected
there, which makes it easier to browse the code.

------
meddlepal
I personally use a pkg directory because I like an uncluttered root and don't
want to end up at some point having a namespace collision with something that
would be better placed in the root directory.

------
awinter-py
go modules have too many weird rules

just import file paths like everyone else -- it's simpler and not obviously
worse

