Hi Sameer, I don't know what is considered an error and not an error with cyclic module dependencies.
Honestly, it makes my head hurt and simply requires too much thought that I'd rather spend on the code. For example, I don't want to think what will happen to some SCC in a module dependency graph after a decade of development, in particular if a module can depend on an earlier version of itself. Scott On 9 September 2018 at 14:19, Sameer Ajmani <sam...@golang.org> wrote: > Are you seeing errors when there are cyclic module dependencies? As I > recall, cyclic dependencies between modules (not packages) must be allowed: > https://research.swtch.com/vgo-mvs > "Note that F 1.1 requires G 1.1, but G 1.1 also requires F 1.1. Declaring > this kind of cycle can be important when singleton functionality moves from > one module to another. Our algorithms must not assume the module > requirement graph is acyclic." > On Sun, Sep 9, 2018 at 7:58 AM Scott Cotton <w...@iri-labs.com> wrote: > >> 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. >> > -- 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.
