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.
