Maybe if I say more it will help the communication/alleviate the disconnection:
First, my overall point is that I have decided to use only acyclic dependencies, as cyclic ones are too complicated for me. I don't feel easily convincible otherwise; that comes from a combination of using go modules where some cycles crept in and a strong bias for a dead simple dependency methodology. Second, there is perhaps some confusion about what "depends" means in this thread. (*) My intuition of what A depends on B means is, in plain English, that A references B in order to work. So one would have to have at least one copy of B in order for A to work, for example. In go.mod, there is a require statement which lists requirements of a module. I have been interpreting requirements as dependencies. Requirements, follow a syntax which usually take the form of a (package, semver) tuple, nicely documented with lots of syntactic variations that, while nice and useful, I honestly hope to avoid having to think about due to my bias above. To me, if A vX.Y.Z (your current module you are working on) requires B v.Q.R.S in go.mod, then that means A vX.Y.Z depends on B v.Q.R.S. In a few cases we've had A=B and Q.R.S < X.Y.Z. There are perhaps technical definitions of dependency in how the system works that differ from how I tend to interpret what a dependency is, as above. If this is the case, it adds to cognitive noise for me because it takes mental effort to understand that I prefer to place elsewhere. Now there is perhaps also some question of "// indirect", as that seems to be involved in the dendency cycles discussed so far. There is some documentation, such as on the wiki, that states that these are transitive dependencies not specified in other dependencies. But it is still presented as a "dependency". Given my intuition of dependency (*) above, cycles simply don't make sense. Not at all, in any finite memory universe :) I am aware that one can refine the dependency order so it all makes sense and works in terms of semver compatibility, as in Paul's experience report. Maybe somewhere in that process and our dialog about it, the idea of compatibility got mixed up with dependency in order to pull off the MVS magic that made it "all work out". Fortunately, for me, I have simple solution: don't use cycles between module dependencies (eg go.mod requirements). I'm afraid however that this leaves me in a relatively uninformed state to inform a discussion about cycles in "how the system works" in much more detail. Best, Scott On Monday, 10 September 2018 07:28:50 UTC+2, Scott Cotton wrote: > > Well, ok. > > Did you mean if A v1.12 of a module depends on v1.3 of B which depends on > v1.11 of A? > > So go modules don't actually necessarily depend on the listed > dependencies? > > That is quite counteruintintive to me. > > It is much simpler in any case to use acyclic dependencies. > > Scott > > On 10 September 2018 at 04:25, Sameer Ajmani <sam...@golang.org> wrote: > >> I think there's a disconnection between how you and I understand this >> system works. In a given build, there is only a single version of a module; >> there cannot be multiple copies, let alone many copies.So if v1.11 of >> module A depends on v1.3 of module B, which in turn depends on v1.12 of >> module A, then the build will choose A v1.12. The is only one version of A >> in the build. >> >> On Sun, Sep 9, 2018 at 1:40 PM Scott Cotton <w...@iri-labs.com> wrote: >> >>> Hi Sameer, >>> >>> Thanks for asking, here are some thoughts, >>> >>> With time, this could create man many many copies of (different >>> versions) of a module. >>> this would slow down fetch, storage, compilation, etc potentially a lot, >>> and it would only >>> get worse and worse over time. >>> >>> if a security patch is applied to the most recent version in a >>> version-compatible space of >>> a module that depends on an earlier version of itself, then the security >>> hole may still exist. >>> Moreover, if the SCC of module dependencies is outside the control of >>> the authors of the >>> module being patched, it seems there is might be no way they could >>> propagate the patch >>> without editing history, which violates the very notion of versioning to >>> begin with. >>> >>> The notion of software moving forward by versioning is in part an >>> increase in reliability, >>> not just security patches, so I would be frightened to use cyclic >>> modules even in code >>> for which I were certain there would be no security patches (like fixed >>> memory, known cpu bounds >>> math algorithms for example) >>> >>> Other than that, it is to me very confusing and counter-intuitive that a >>> version of some software >>> depend on a previous version of itself. Maybe I'm missing something in >>> the modules >>> specification or vision, and maybe, (even hopefully) I am wrong about >>> these concerns. >>> >>> I could list more related ideas, but given that I might be wrong I'll >>> leave it at that. >>> >>> Thanks, >>> >>> Scott >>> >>> >>> On 9 September 2018 at 19:19, Sameer Ajmani <sam...@golang.org> wrote: >>> >>>> If a module depends on an earlier version itself, and successive >>>> versions are backwards compatible, why is it not OK for the current >>>> version >>>> to satisfy that dependency? >>>> >>>> On Sun, Sep 9, 2018 at 1:13 PM Scott Cotton <w...@iri-labs.com> wrote: >>>> >>>>> 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 >>>>> >>>>> >>>>> >>> >>> >>> -- >>> Scott Cotton >>> President, IRI France SAS >>> http://www.iri-labs.com >>> >>> >>> > > > -- > Scott Cotton > 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.
