Avoid forcing my module users' to carry dependencies from code that live under the same repo just as examples/ debugging purposes.

[Pablo Caballero]

I made a very simple module (the very first one that I uploaded to my GitHub account). I had a main.go file in the root directory used just for testing/debugging (and to keep as an example of how to use the module). Then I "go got" my module from another project just to see that this project transitively got dependencies used only by my module's main.go file (pretty obvious that this was going to happen and also that it's not desirable) and not used by my module logic.

To avoid this, I moved the main.go and related files to a sub-directory called "examples" and created a new go.mod file there. The final structure was something like this:

go.mod (github.com/myuser/mymodule)

my-module-logic.go

internal/*

examples/main.go

examples/go.mod (github.com/myuser/mymodule/examples)

Now when I "go get" my module from another module I don't see the unwanted dependencies anymore but I feel like I'm not following best practices here... especially because I was hit by some negative consequences:

* now I must "go get github.com/myuser/mymodule" from "examples"

* while making changes to my module (I use Goland because it's provided by the company I work for) and debugging it using the examples/main.go as an entry point (yes, I know that strictly speaking, doing that, I'm debugging my module as a "side effect" from debugging the example ) I find myself walking through the source code from the version of my module that I "go got" last (and not through the source that I'm actively working on)

Sorry if I'm asking something obvious here (I tried to do the homework) 

I really appreciate any help.

Best!

Pablo

[Jim Idle]

You might start with this repo:

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

This is not an 'official' standard, though it does encapsulate the things that are standard go such as the internal directory. 

Personally I avoid its recommendation to use a directory 'pkg' to store your module code as it makes the import path quite strange. But for a main you can look at the cmd directory or the internal directory. You will not go too far wrong by following this guide.

Jim

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAPxFe-ur4cURAmCRFJa0QpTHaL3CHCt_Lz%2BZkWK4N1hiL5Bd0A%40mail.gmail.com.

[Dan Kortschak]

On Fri, 2023-04-14 at 14:01 +0800, Jim Idle wrote:
> You might start with this repo:
>
> https://github.com/golang-standards/project-layout
>
> This is not an 'official' standard, though it does encapsulate the
> things that are standard go such as the internal directory. 
>
> Personally I avoid its recommendation to use a directory 'pkg' to
> store your module code as it makes the import path quite strange. But
> for a main you can look at the cmd directory or the internal
> directory. You will not go too far wrong by following this guide.
>
> Jim

It's worth noting this issue in that repo:
https://github.com/golang-standards/project-layout/issues/117

[Jim Idle]

Indeed. Some parts of it are fine though, given that the ask was for a starting point. I agree completely with the pkg stuff being wrong. I use just some of the ideas here, but I don’t see what the point of pkg is. 

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c66f416360824816fa1c9415126c78969beaad9b.camel%40kortschak.io.