Hi all, One additional set of brief comments.
This was a fairly nuanced and long thread, and I'm pretty sure I did not follow all of it, but I think a question related to the conversation here is -- what does 'require foo v1.1.1' really mean? Perhaps one way to think about that usage of the verb 'require' is that it really needs to be read in the context of semantic versioning (https://semver.org). If something states it requires v1.1.1 of foo, in the context of semantic versioning that really means that particular requirement for v1.1.1 would be satisfied by foo >= v1.1.1 and < v2, given semver defines versions in that interval to be valid and backwards compatible substitutions for v1.1.1 (and anything v2 or higher is considered incompatible with any v1 version). And a variation of that first question is -- what does it mean for a build if you have both a 'require foo v1.1.1' and a 'require foo v1.2.2'? One initial guess might be that the build ends up with two copies of foo (v1.1.1 and v1.2.2) given there are two 'require' statements with those two different versions. That is a reasonable guess, but not actually what happens. If you instead read that verb 'require' in the context of semantic versioning, it means that if the build instead picks a _single_ copy of foo at version v1.2.2, that actually would satisfy _both_ of the requirements for v1.1.1 and v1.2.2 (given v1.2.2 is defined by semver to be a backwards compatible substitution for v1.1.1). And of course, this is what the go build system actually would do in this scenario. Said another way, when you use modules, the go command _mandates_ that modules use semantic versioning and expects that the versions accurately describe compatibility: it assumes that v1.2.2 is a backwards compatible replacement for v1.1.1, and hence v1.2.2 is a valid answer if you have both 'require foo v1.1.1' and a 'require foo v1.2.2'. In any event, this is all still fairly new, and everyone is still learning about the overall system. (The broader community is of course learning about the new system, but even the people who implemented this system are in a learning phase, including because they are learning about how the community will use the new system). --thepudds On Saturday, September 15, 2018 at 1:11:49 PM UTC-4, Scott Cotton wrote: > > Thanks! Very useful. > > +1 for aliasing "go mod list" to "go list -m" > > > > > > On 15 September 2018 at 18:59, <thepud...@gmail.com <javascript:>> 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/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 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...@googlegroups.com <javascript:>. >> 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.
