golang.org says to use a src/ directory

[dwschulze]

Your comments on the use of a src/ directory aren't correct, at least in the GOPATH approach which has been the recommendation in the past: https://golang.org/doc/gopath_code.html

Here's what happens if you don't have a src/ directory in your project:

lctl.go:3:8: cannot find package "lctlutil" in any of: /home/dean/bin/go1.14.linux-amd64/go/src/lctlutil (from $GOROOT) /home/dean/src/golang/integration/lctl/src/lctlutil (from $GOPATH) /home/dean/src/golang/go3p/src/lctlutil

Go looks for a src/ directory.

Also the link in that section points to an updated page which doesn't mention the src/ directory. Apparently it has been updated for modules.

[hielfx]

HI, if I am not mistaken, with GOPATH you need the src directory because it's a workspace and the workspace needs a bin and a src folder: https://golang.org/doc/gopath_code.html#Workspaces

For go modules, you can structure your project however you like because it's not constrained by the GOPATH variable so you "don't have the need to use a src folder" (you can still use it though).

Hope it helps!

[tsatke]

That is correct. You should use go modules now anyway, so no source directory needed. Also, the source directory is a global one, and not per project.

[tetrahedronix]

I'd like if the src directory is replicated in any software project according to the OSS standard. For example, John's Jupiter project

john/
john/jupiter/doc
john/jupiter/src
john/jupiter/Makefile
john/jupiter/src/Makefile
john/jupiter/src/api
john/jupiter/src/build
...
john/jupiter/src/vendor

Moreover I'd love if there be a tool like autoproject to configure Go projects.

[rubens21]

The project layout proposal says: Don't confuse the project level /src directory with the /src directory Go uses for its workspaces as described in How to Write Go Code

I think that is exactly what you are confusing.

The Go documentation talk about the src dir used by Go before Go 1.13. (https://golang.org/doc/gopath_code.html#Workspaces) That directory structure used to allow Go finding the project dependencies. It is not necessary anymore.

On the other hand, the project layout proposal is talking about having a src directory in your project.

[tetrahedronix]

The project layout proposal says: Don't confuse the project level /src directory with the /src directory Go uses for its workspaces as described in How to Write Go Code

I think that is exactly what you are confusing.

Negative, I'm saying to include your project-layout in src directory of the project to comply with the OSS standard. Anyway It's a matter of personal preference. No problem.

[rubens21]

@tetravalence, please read my comment carefully. I did not mention your comment.

My comment was about the project layout proposed by this repo, not about your proposal.

[Luc45]

Hey!

If not src, where should I put my .go files? I found this guide a great resource to organize everything you could need around the actual source code, but I didn't understand where I should put the actual source code at.

Thanks!

[Tockra]

Hey!

If not src, where should I put my .go files? I found this guide a great resource to organize everything you could need around the actual source code, but I didn't understand where I should put the actual source code at.

Thanks!

I assume you need to put a main.go to cmd/application_name and the rest to internal/application_name/ .

It feels weird to use this project structure if you just want to write one application. But I think the main idea is to give a structure for bigger projects which contains more applications/microservices which are connected (maybe).

[arvenil]

Go itself uses src directory for standard library. Every single *.go file of golang is in src/ directory. https://github.com/golang/go/tree/master/src

[Tockra]

@arvenil this is the structure of the go project. How do you know this is a official structure? I saw no official documentation introduce this structure. Maybe you should look where you are:

https://github.com/golang-standards/project-layout#directories-you-shouldnt-have

[tsatke]

@arvenil Go itself does a lot of things that you shouldn't do. It's generally a bad idea to adapt something just because someone else does it. There's a lot of good reason behind why you shouldn't, one of them being having to write github.com/user/repo/src instead of simply github.com/user/repo to get access to public API. This is a problem that you don't have with the Go codebase.

[sj14]

With the Go module support, I'm really thinking of adding a src folder to my projects to unclutter the root folder. Are there any good up-to-date reasons not to do this?

[sj14]

There's a lot of good reason behind why you shouldn't, one of them being having to write github.com/user/repo/src instead of simply github.com/user/repo to get access to public API. This is a problem that you don't have with the Go codebase.

If I'm not mistaken, most times the packages are also not in the root of the repo (there also can be only one at max), so you would have to import something like github.com/user/repo/xyz or github.com/user/repo/pkg/xyz too.

But I'm genuinely curious about the other good reasons.

[tsatke]

Are there any good up-to-date reasons not to do this?

I think smaller codebases up to a few thousand lines of code can work with only the root folder. Above that, you might want to think about your architecture a little, and split the code across meaningful packages. Generally, I don't like introducing packages just do declutter the code. If you have a lot of code that belongs together, like a set of structs and their implementations, and that implementation does not depend on other stuff in your codebase, extract it into a package. If it depends on other stuff, consider extracting that stuff into a separate package first.

Go doesn't allow for circular dependencies, which is why you have to be clean when introducing packages.

But I'm genuinely curious about the other good reasons.

Well you are right, but if you import github.com/user/repo/mypkg, you want to use the functionality of mypkg. You would have to import github.com/user/repo/src to use code in repo, though. That isn't a problem, but it doesn't read nice, however, IDE support could probably make up for it.

[pimguilherme]

it is indeed somewhat weird that the main go project uses a src directory and that doesn't stick with the community.. even a bit weirder that it used to use the pkg/ structure within src, but then removed that as well

but also it is a different type of project, that isn't imported like other Go projects, because it's already internally present with no need to fetch from github

personally I like to separate things, and would love if the community had picked the src/ approach, but since we're basically already separating the code into three directories (pkg, internal and cmd), it doesn't feel like a crazy amount of folders.. and it feels good to be aligned with the community :raised_hands:

[tetrahedronix]

I don't think I'll ever adopt this standard. I prefer a different approach. This feels too reminiscent of the 'mess' you often see in the source code of programs written in Java, PHP, or Python. As a programmer, I value clarity and organization, and I'll stick to the OSS approach that aligns with those principles.

it is indeed somewhat weird that the main go project uses a src directory and that doesn't stick with the community.. even a bit weirder that it used to use the pkg/ structure within src, but then removed that as well

but also it is a different type of project, that isn't imported like other Go projects, because it's already internally present with no need to fetch from github

personally I like to separate things, and would love if the community had picked the src/ approach, but since we're basically already separating the code into three directories (pkg, internal and cmd), it doesn't feel like a crazy amount of folders.. and it feels good to be aligned with the community 🙌