> "Maybe having a way for "go mod" to output what is used would be less confusing?"
Hi all, To see a list of the selected module versions, one way is to use use 'go list -m all'. This shows the actual versions used based on all of the various requirements in a build. Sample output: $ go list -m all example.com/my/module github.com/aws/aws-sdk-go v1.15.35 github.com/go-ini/ini v1.25.4 Another other useful tool is for inspecting requirements is 'go mod graph' (which prints the module requirement graph), and if you are curious why a particular module is showing up in your go.mod, you can run 'go mod why -m <module>' to answer that question. You can read some more about these here: https://tip.golang.org/cmd/go/#hdr-The_main_module_and_the_build_list https://tip.golang.org/cmd/go/#hdr-Explain_why_packages_or_modules_are_needed https://tip.golang.org/cmd/go/#hdr-Print_module_requirement_graph The first link above also provides a short description of the build list, which is related to several of the questions raised in this thread: ---------------- "The set of modules providing packages to builds is called the "build list". The build list initially contains only the main module. Then the go command adds to the list the exact module versions required by modules already on the list, recursively, until there is nothing left to add to the list. If multiple versions of a particular module are added to the list, then at the end only the latest version (according to semantic version ordering) is kept for use in the build." ---------------- --thepudds On Saturday, September 15, 2018 at 6:34:55 AM UTC-4, Scott Cotton wrote: > > Thanks for the clarification. > > Maybe having a way for "go mod" to output what is used would be less > confusing? I would have found so at least. > > Cycles crossing major versions may be more problematic. > > similarly in the case of coordinating a collection of modules, dependency > cycles may lead unintentionally to different used versions > depending on the build context. While the potential use of multiple > versions is a useful feature of modules, I am not convinced > that in this context it is desirable. Also, if cycles can span > arbitrarily large sets of uncoordinated modules, then it seems to me that > is not the intended use case for cycles and that might be undesirable or > even lead to the inability of a module maintainer in the cycle > to effectively propagate an update. > > If I come across anything more concrete, I'll file an issue. Just food > for thought at this point. > > Best > Scott > > On Saturday, 15 September 2018 02:45:50 UTC+2, Sameer Ajmani wrote: >> >> 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 <pa...@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...@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.
