Thanks! Very useful. +1 for aliasing "go mod list" to "go list -m"
On 15 September 2018 at 18:59, <thepudds1...@gmail.com> wrote: > > "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/79c3f12372e13b0cbbdf0411c8c46 >>>>>>>>>>>>> fd5 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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 a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/golang-nuts/h2r8ktgOOZI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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.
