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 அன்று, <thepudds1...@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 > > 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 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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Sankar P http://psankar.blogspot.com -- 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.
