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 On Sunday, October 21, 2018 at 12:31:34 PM UTC-4, Sankar wrote: > > 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. > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
