And incidentally, #modules on Gophers Slack will likely be a better
place to work things through; it's got a great number of people
helping/responding.
On Wed, 8 Aug 2018 at 17:28, Paul Jolly <p...@myitcv.io> wrote:
>
> Cole - apologies, things got busy in the last few weeks so this thread
> dropped off my radar.
>
> You've raised a number of questions in this thread; how many of these remain
> since the release of beta3? Or indeed the fixes that have hit go tip since
> beta3?
>
> Happy to work through anything that's outstanding.
>
> Thanks,
>
>
> Paul
> On Fri, 27 Jul 2018 at 01:38, Cole Davis <wcole.da...@gmail.com> wrote:
> >
> > Nesting a module in cmd/service allows the correct code to be used but
> > confuses the tool. The layout of the project was one that was heralded
> > prior to vgo I believe so I don't know if they are incompatible.
> >
> > Here's the structure in more detail
> >
> > $GOPATH/src/path/to/shared/
> > a/
> > b/
> > c/
> > go.mod
> >
> > $GOPATH/src/path/to/service/
> > cmd/
> > service/
> > {...imports "path/to/service/pkg/d", "path/to/shared"...}
> > pkg/
> > d/
> > {...imports "grpc"...}
> > go.mod
> >
> > Prior to switching to vgo/go1.11beta2 we used dep. From the root of the
> > service I could do `go build -x -a -v -o ./service ./cmd/service` and it
> > would build fine. Using modules I'm seeing a couple issues. It seems like
> > the modules are competing with each other. If I use `go mod -sync` in the
> > cmd/service module directory it has an ambiguous import error with itself.
> > It doesn't import itself so I'm not sure where that is coming from. If I
> > manually add the requires that should let it compile I still have to have
> > some requires in the root so that the pkg/d package can build. It just so
> > happens there is some overlap in their imports so it seems redundant to
> > have it in both modules (root and cmd/service) not to mention running `go
> > mod -sync` from the root has all sorts of unnecessary indirect requires
> > added some of them only useful in cmd/service but it's ignore that it has a
> > go.mod file apparently. All that to say if I run the build command that
> > used to work from the root too it has the same ambiguous import error.
> >
> > Looking at the output it appears that it's attempting to download the
> > cmd/service package from remote instead of building it from the local
> > source.
> >
> > Do the structure of projects need to change to accommodate go modules and
> > working with local development versions of dependencies?
> >
> > On Thursday, July 26, 2018 at 5:08:07 PM UTC-7, Cole Davis wrote:
> >>
> >> Since I posted this question earlier today I've actually come to a better
> >> understanding of this. I was a bit confused on how "packages" fit into the
> >> "module" relationship. A couple things I've found that appear to be true:
> >> - not every package in a module needs to be its own module unless you
> >> intend to version it separately from the root module
> >> - the root module need not have go code in the root as long as it has
> >> packages in its tree
> >> - the idea to point your module at a local directory while developing is
> >> via the -replace flag/go.mod entry
> >>
> >> So, this all solved part of my issue but I've run into something else I
> >> don't know if it's a bug or yet more I don't understand. I have a
> >> repository that is now a module that contains multiple packages of shared
> >> utility. They all build/test fine everything looks just dandy. But I
> >> haven't committed the changes or pushed them anywhere. I wanted to test
> >> the changes against a service in another repository that imports it. I
> >> converted the service to a module in its repository root. The layout of
> >> the project has the main service in a structure such as
> >>
> >> repo-root/
> >> go.mod
> >> cmd/
> >> service/
> >>
> >> go.mod in this case has all of the dependencies in require and
> >> vgo/go1.11beta2 seems happy to build against old cached code. When I use
> >> replace it parses it fine, it points to the correct directory, but appears
> >> to be ignored.
> >>
> >> If I instead add a go.mod to service/ and add the replace there it
> >> immediately reflects the desired code but I would have to move my requires
> >> into that go.mod it seems because the one in root no longer applies (even
> >> though the same imports are reflected by the roots requires and those
> >> modules can be found in the GOPATH anyway).
> >>
> >> Is it intentional that replace is not respected as a root of a
> >> module...there are other packages in this repository for the service.
> >> Would I have to treat service/ as a module on its own to get that to work?
> >> That doesn't seem right.
> >>
> >> On Thursday, July 26, 2018 at 4:52:55 PM UTC-7, Cole Davis wrote:
> >>>
> >>> Hi Paul,
> >>>
> >>> Does this imply that, to test local changes in the inter-dependent sub
> >>> modules you have to commit each change and push (much less tag) to be
> >>> able to test the changes or have them reflected in local builds?
> >>>
> >>> This is the behavior I'm seeing using beta2 and converting a repository
> >>> that has a couple of separate but related/dependent packages. The repo is
> >>> still in my standard GOPATH. When I try to build one of the sub modules
> >>> that is dependent on a peer module it downloads an older version of the
> >>> repository and then complains about "ambiguous import" listing the local
> >>> GOPATH location and the sub module from the downloaded and cached sub
> >>> module in $GOPATH/src/mod/...
> >>>
> >>> Also, should each sub module have its own require statements or should
> >>> they all be in the root go.mod file?
> >>>
> >>> Thank you.
> >>>
> >>> On Wednesday, July 25, 2018 at 9:12:01 AM UTC-7, Paul Jolly wrote:
> >>>>
> >>>> > Multiple modules in single repo, currently a supported layout?
> >>>>
> >>>> Absolutely. Here's a complete example:
> >>>>
> >>>> $ mkdir go-modules-by-example-submodules
> >>>> $ cd go-modules-by-example-submodules
> >>>> $ git init -q
> >>>> $ git remote add origin
> >>>> https://github.com/myitcv/go-modules-by-example-submodules
> >>>> $ go mod -init -module github.com/myitcv/go-modules-by-example-submodules
> >>>> go: creating new go.mod: module
> >>>> github.com/myitcv/go-modules-by-example-submodules
> >>>> $ git add go.mod
> >>>> $ git commit -q -am 'Initial commit'
> >>>> $ git push -q
> >>>> $ mkdir b
> >>>> $ cd b
> >>>> $ cat <<EOD >b.go
> >>>> package b
> >>>>
> >>>> const Name = "Gopher"
> >>>> EOD
> >>>> $ go mod -init -module
> >>>> github.com/myitcv/go-modules-by-example-submodules/b
> >>>> go: creating new go.mod: module
> >>>> github.com/myitcv/go-modules-by-example-submodules/b
> >>>> $ go test
> >>>> ? github.com/myitcv/go-modules-by-example-submodules/b [no test
> >>>> files]
> >>>> $ cd ..
> >>>> $ git add b
> >>>> $ git commit -q -am 'Add package b'
> >>>> $ git push -q
> >>>> $ git tag b/v0.1.1
> >>>> $ git push -q origin b/v0.1.1
> >>>> $ mkdir a
> >>>> $ cd a
> >>>> $ cat <<EOD >.gitignore
> >>>> /a
> >>>> EOD
> >>>> $ cat <<EOD >a.go
> >>>> package main
> >>>>
> >>>> import (
> >>>> "github.com/myitcv/go-modules-by-example-submodules/b"
> >>>> "fmt"
> >>>> )
> >>>>
> >>>> const Name = b.Name
> >>>>
> >>>> func main() {
> >>>> fmt.Println(Name)
> >>>> }
> >>>> EOD
> >>>> $ go mod -init -module
> >>>> github.com/myitcv/go-modules-by-example-submodules/a
> >>>> go: creating new go.mod: module
> >>>> github.com/myitcv/go-modules-by-example-submodules/a
> >>>> $ go build
> >>>> go: finding github.com/myitcv/go-modules-by-example-submodules/b v0.1.1
> >>>> go: downloading github.com/myitcv/go-modules-by-example-submodules/b
> >>>> v0.1.1
> >>>> $ ./a
> >>>> Gopher
> >>>> $ cat go.mod
> >>>> module github.com/myitcv/go-modules-by-example-submodules/a
> >>>>
> >>>> require github.com/myitcv/go-modules-by-example-submodules/b v0.1.1
> >>>> $ cd ..
> >>>> $ git add a
> >>>> $ git commit -q -am 'Add package a'
> >>>> $ git push -q
> >>>> $ git tag a/v1.0.0
> >>>> $ git push -q origin a/v1.0.0
> >
> > --
> > 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.
--
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.
