go src organization question

[Sankar]

Hi,

We were using go 1.7 until recently and now want to switch to 1.11 and start using go modules.

Currently our source organization is as follows:

~/go/src/gitlab.com/example/

                                   |

                                   |

                                   example/

                                        |

                                        |

                                        |api/

                                        |   |

                                        |   main.go (imports library1, library2 and some 3rd party libs)

                                        |library1/

                                        |   |

                                        |   lib1.go

                                        |library2/

                                        |  |

                                        |  lib2.go

In our main.go, We were importing packages like:

```

"gitlab.com/example/example/library1"

"gitlab.com/example/example/library2"

"gitHUB.com/3rdpary/library"

```

We actually wanted to import library1 and library2 via relative path ("../library[12]") but since the go compiler did not support relative imports then, we used the absolute imports. We did not use any dependency management tool (like dep, glide etc.).

The libraries that we write (library1 and library2) need not be versioned and will always be used in a reliable state in our api/main.go

We however need versioning support for our 3rd party libraries.

For such a hybrid requirement, what is the most recommended way to import and structure our libraries and the source directories, to work with go modules ? I tried reading through https://github.com/golang/go/wiki/Modules but I could not find out any recommended way for this. Any help on how I can do this ? Do I need to create `cmd` or `src` folders in our git repo ? OR do we need to do something else ? Any links for blogposts, tutorials, documentation, videos etc. will be helpful. Thanks.

[thepud...@gmail.com]

Hi Sankar,

How many repos are you directly modifying?

Most projects are likely following the simplest approach of using a single module per repository, which typically would mean creating one go.mod file located in the root directory of each repository. (The official modules proposal predicts that is what most projects will do: https://go.googlesource.com/proposal/+/master/design/24301-versioned-go.md ).

Separately, I believe you are correct that relative import paths are not supported with modules. See this FAQ on the modules wiki: https://github.com/golang/go/wiki/Modules#do-modules-work-with-relative-imports-like-import-subdir and the related issue https://github.com/golang/go/issues/26645#issuecomment-408572701, which includes this comment:

   > In modules, there finally is a name for the subdirectory. If the parent directory says "module m" then the subdirectory is imported as "m/subdir", no longer "./subdir".

If you end up with one module per repo, a related question would be how many modules are you editing at roughly the same time? If that is part of your concern or question, then there are a few different options there. I'll include a few pointers here for things to review and consider, but then after looking over those, you might want to circle back here with additional questions or comments on your use case.

For editing multiple modules at the same time, one approach is to use the 'replace' directive to point to local copies. You can read a bit more about that in this FAQ on the modules wiki:

  "FAQ: When should I use the replace directive?"

   https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive

   

A related but more automated approach is github.com/rogpeppe/gohack, which is a new community tool to automate and simplify 'replace' and multi-module workflows, including allowing you to easily modify one of your dependencies. For example, 'gohack example.com/some/dependency' automatically clones the appropriate repository and adds the necessary replace directives to your 'go.mod' so that you can edit that dependency and build using those edits, all locally and without requiring you to commit anything yet. You can read more about 'gohack' at the repo, or you can also see a worked example of using 'gohack' at the 'Go Modules by Example' site here: https://github.com/go-modules-by-example/index/blob/master/011_using_gohack/README.md

   

There are several more options as well for multi-module workspaces, including the core go tooling seems to have been built to make it possible to build more specific tools on top. There's an overview of several of the options in the following thread, including possibly using commit hooks, or using pre-release semver tags, etc., as well as some pointers to related discussion issues in the tracker:

  https://groups.google.com/d/msg/golang-nuts/0KQ4ZuSpzy8/5m4Ek7q2BgAJ

Sorry that is probably not 100% answering your question, but perhaps you can say a bit more about your specifics, which then likely will trigger some more specific comments from this list.

--thepudds

[Sam Whited]

On Sun, Oct 21, 2018, at 11:31, Sankar wrote:
> For such a hybrid requirement, what is the most recommended way to import
> and structure our libraries and the source directories, to work with go
> modules?

A single module at the root of the project should give you what you want. Create the file: ~/go/src/gitlab.com/example/go.mod
and then add the line:

module gitlab.com/example

and build. Everything should work and the local copy of your libraries will be used because they are in the same module.

—Sam

[Sankar P]

I am yet to go through your mail in detail. But I will answer the primary question first. I have a monolithic repository which contains all my go backend related code in a single project. I have about 8 packages that are internally defined inside my repo, and I do not need any version management for any of them. All of these are very specific to my project and some are just structs.

I have about 5 third party packages which I depend on and some of them are quite popular, like the pq driver for postgres, dgrijalva/jwt-go, etc., So over all about a dozen packages are dependencies in total.

ஞாயி., 21 அக்., 2018, பிற்பகல் 11:32 அன்று, <thepud...@gmail.com> எழுதியது:

--
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/Bf8fDyfbTUw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Sankar P
http://psankar.blogspot.com