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.
