You do have the option to nest one module within another module in the same
repo, but from what I have seen, that is usually not what one wants to do,
and especially not to start. It can be tricky to set up correctly, and
usually is more work on an on-going basis.
The clearest statement I've seen might be Russ Cox wrote in #26664:
"For all but power users, you probably want to adopt the usual
convention
that one repo = one module. It's important for long-term evolution of
code
storage options that a repo can contain multiple modules, but it's
almost
certainly not something you want to do by default."
In terms of your question about each child module being able to specify
it's own dependencies, that is a more nuanced question, but hopefully this
at least conveys the gist...
If you have a single go.mod with multiple packages, that go.mod will track
the dependencies across all packages, which usually works reasonably well
in practice for most projects.
If we take the example where package foo and bar reside in a single module,
it is usually not a problem for example if:
1. foo and bar both require the same v1+ major version of some dependency
X (including given X should be compatible within a v1+ major version,
according to semver).
2. foo and bar require different major versions of dependency Y (including
given Y can be separately tracked within a single go.mod as require Y/v2
and require Y/v3).
It would however be a problem if:
3. package foo requires a v0 version of some dependency Z that is
incompatible with the v0 or v1 version of Z required by bar (because at
most one v0/v1 version of dependency Z would be tracked within a single
go.mod).
4. if foo and bar require different incompatible versions of a shared
dependency that does not follow https://semver.org. (Following semver is a
requirement for any code opting in to modules, but pre-existing code will
not have always followed semver).
Perhaps your logging example would fall into the second case of needing to
use different major versions in a single build? If so, modules allow that.
If you weigh the pros and cons and really do feel the need to nest modules
within a single repo, the modules wiki has an entire section dedicated to
that, which I would encourage you to read carefully if you do go down that
path. As you'll note, though, there is some nuance there:
https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories
Regards,
thepudds
On Saturday, April 20, 2019 at 8:57:09 AM UTC-4, whiteh...@googlemail.com
wrote:
>
>
> https://github.com/golang/go/wiki/Modules#can-i-work-entirely-outside-of-vcs-on-my-local-filesystem
>
> For a simple parent/child module relationship this seems to work, since
> the 'replace' work-around is in the parent go.mod.
> But when the childA depends on childB, then the 'replace' directive in
> childA's go.mod is ignored, and the build fails. According to the above
> information this is working as designed.
>
> Since there is no error feedback that the 'replace' directive has been
> ignored, I eventually stumbled over a couple of similar reported issues.
> Which is how I also found the information that sub-module 'replace'
> directives are being ignored.
>
> https://github.com/golang/go/issues/29376
> https://github.com/golang/go/issues/31345
>
> Since I'm just learning Go I would like to understand the approach
> better. I come from a Maven background for dependency management. Here it
> is a common pattern to have a parent/child module design. Each child
> module can specify it's own dependencies. And in complex projects two
> different sub-modules or sub-sub-modules may even have requirements on
> different versions of the same library (Logging I'm looking at you!).
>
> So this question is also applicable when running under VCS. ie that Go
> sub-modules may want to specify a specific version of a library that they
> depend upon using the replace directive.
>
> Anyway I am left with the impression that this parent/child module pattern
> might be considered non idiomatic in the Go world? ie Go is targeting a
> 1-to-1 mapping of VCS project to Module. Is that fair to say?
>
>
--
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.
