Hi Paul, Yes I see that in terms of compatibility it "all works out", but it seems underspecified what should happen. Also, although your experience reports are clearly presented and make sense, when I step back my own impression is: that's not simple. I'd rather be spending time coding than figuring out or worrying about chains of cyclic dependencies going back in time indefinitely.
Scott On 9 September 2018 at 14:55, Paul Jolly <p...@myitcv.io> wrote: > > Interesting. I'm not sure what cyclic module dependencies means. I do > know some package managers (not go) boast of having a "solid transitive > dependency model". I hope that any cycles in modules dependencies are > either avoided or treated in a very clear simple way by go's modules. > > In my experience report I explain how the situation comes about in the > case of GopherJS. The "reverse" dependency (i.e. the one that makes > the cycle) is, I suspect, typically (always?) going to be something to > do with testing. > > > Unfortunately, my concrete example is lost in sands of time, so I can > only give a rough idea. I had cyclic module dependencies, somewhat > unintended, but it crept in via some test case. I was playing with 111 or > late 111 release candidate with it and asked it to rebuild go.mod at an > untagged HEAD (I think) that was a few commits ahead of say v0.1.2. Then > go.mod had that my module required v0.1.1 of itself in go.mod > "indirectly". All I could figure out was that the module dependency cycle > A -> B -> A had B depending on an older version of A via a test case. > > I suppose you could say that transitively this module depends on the > same major version of itself, yes. > > The same is true in my experience report. And it's by definition that > you end up with a reference to and "older" version because of the > existence dependence of the modules. > > But because of semantic import versioning (i.e. same major version in > this situation) and compatibility within that major version, > everything works out, even when running go test all from either of the > modules involved in the cycle. > > I found this easiest to reason about by looking at the process > involved with _introducing_ the submodule in the GopherJS repo that > creates the cycle: > > https://gist.github.com/myitcv/79c3f12372e13b0cbbdf0411c8c46f > d5#the-process > > > Paul > -- Scott Cotton President, IRI France SAS http://www.iri-labs.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.
