RFC Package structuring

[Sankar]

I am starting a new project (say `hello`) and I am totally confused about what package structure to use. 

I am going to go with a monolithic source repository which would be checked out under `~/src` directory in the developer machines.

I have three golang binaries available in my project.

1) hello-cli : A tool that would give me a CLI, which will be used from my client machines. Say something similar to the docker-cli

2) hello-daemon: A daemon to which the CLI tools will talk to. Say something similar to docker-daemon

3) hello-api-server: A HTTP server to which the daemon will talk. Say something similar to dockerhub API server.

In addition to these three golang binaries, I may have other things like a webui, some static assets, some integration tests etc. in multiple languages.

There will be some libraries that will be used by each of the golang binaries that will be internal only to the specific binaries and there will be some libraries, which will be shared across the three binaries. The three binaries may depend on different versions of the libraries.

Now the package structure that I thought was:

Will this be good or should I make any change ? I am not sure if vendoring would work fine here as there would be no `github.com/` etc. prefix (or even GOPATH) as I want to checkout under a special path (`~/src`).

I have attached the hello.zip file also. Does this package structure work ? Or should I do something different ?

Thanks.

[hartzell]

On Saturday, February 29, 2020 at 10:03:34 AM UTC-8, Sankar wrote:

I am starting a new project (say `hello`) and I am totally confused about what package structure to use.  [...]

  

You might find the project-layout notes from the golang-standards GitHub organization (which seems to be a one-person org) useful:

https://github.com/golang-standards/project-layout

It has some good ideas and links to other discussions and resources.

I'd avoid hard coding any knowledge of where the tree's checked out (I often clone things into ~/tmp to monkey with them).

g.

[Sankar P]

ஞாயி., 1 மார்., 2020, முற்பகல் 4:17 அன்று, hartzell <hart...@alerce.com> எழுதியது:

On Saturday, February 29, 2020 at 10:03:34 AM UTC-8, Sankar wrote:

I am starting a new project (say `hello`) and I am totally confused about what package structure to use.  [...]

  

You might find the project-layout notes from the golang-standards GitHub organization (which seems to be a one-person org) useful:

https://github.com/golang-standards/project-layout

Yes, I did check that. But that link has files for only one single executable. I am looking for a monolithic repository with multiple executables and multiple libraries. 

 

It has some good ideas and links to other discussions and resources.

I'd avoid hard coding any knowledge of where the tree's checked out (I often clone things into ~/tmp to monkey with them).

Yes, I too want this only. But how to get vendor and dependents working in this case is what is unclear to me. 

 

g.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/s062Xbtb7ys/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/09bb6e93-acd7-4fcd-8178-fb99a2e56028%40googlegroups.com.

--

Sankar P
http://psankar.blogspot.com

[haskell...@yahoo.de]

1 go.{mod|sum} per repository, no vendoring

tree/
 angular-ui/
 cmd/
   hello-api-server/
   hello-cli/
   hello-daemon/
 internal/
   internal-lib1/
   internal-lib2/
 library1/
 library2/
 library3/
 python-tests/
 go.mod
 go.sum

[Rizwan Iqbal]

I would avoid multiple go.mod files in one repository as well. I generally follow the rule of thumb, one module per repository.

On Saturday, 29 February 2020 19:03:34 UTC+1, Sankar wrote:

[Sam Whited]

On Tue, Mar 3, 2020, at 10:09, Rizwan Iqbal wrote:
> I would avoid multiple go.mod files in one repository as well. I
> generally follow the rule of thumb, one module per repository.

I generally follow this advice too, however, I make an exception for
modules that don't need to be versioned. For example, I keep a separate
module for "example" or "demo" directories so that their dependencies
don't wind up in my libraries go.mod file. This isn't a problem though
because I'll never tag or version the demos, they're just there to give
you an example of how to use the library.

—Sam