Hi Sameer, When I had a module self-dependency, I considered the fact that it worked a bug. I had not followed closely enough til this discussion to think of it as expected.
As someone who has a tendency to often ask themself: "worse case how can this be a problem?" the list is indeed long and severe for modules which depend on themselves backwards in time. For cyclic dependencies which are somehow synchronised so that there is no backwards in time propagation, my impression would be "that's complicated", but I can't see offhand how it would be as problematic as backward in time self dependencies. Scott On 9 September 2018 at 18:38, Sameer Ajmani <sam...@golang.org> wrote: > 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 >> >> >> -- 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.
