Hi Paul, On 9 September 2018 at 13:44, Paul Jolly <p...@myitcv.io> wrote:
> Hi Scott, > > > Should cyclic module dependencies be allowed? > > Yes, indeed in some situations they are totally necessary. > > I wrote up an experience report on this very topic: > https://gist.github.com/myitcv/79c3f12372e13b0cbbdf0411c8c46fd5 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. > > > > Should a module, following a cycle, be able to depend on an earlier > version of itself? (I saw this once...) > > I can't see how this would work; indeed I can't even unravel it in my > head! Do you have a concrete example to help explain? > 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. Scott > > Thanks, > > > 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.
