> 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/79c3f12372e13b0cbbdf0411c8c46fd5#the-process Paul -- 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.
