Go modules can use the listed version or later minor versions. So if B depends on v1.11 of A, then it can also work with v1.12 of A. Therefore a valid set of versions for the build is A v1.12 and B v1.3.
On Mon, Sep 10, 2018 at 1:28 AM Scott Cotton <w...@iri-labs.com> 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.
