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 > > > -- 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.
