With respect to errors, I'm asking how things failed when you had a cyclic module dependency. My expectation is that this should just work. If your module 0.12 has a dependency on itself with min version 0.11, then 0.12 satisfies that dependency (as long as it's following the import compatibility rule, which isn't necessarily expected for pre-1.0 modules).
On Sun, Sep 9, 2018 at 9:10 AM Scott Cotton <w...@iri-labs.com> wrote: > 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.
