Thanks. The relationship between semantic versioning and Go packages is described in detail here: https://research.swtch.com/vgo-import On Sat, Sep 15, 2018 at 3:52 PM <thepudds1...@gmail.com> wrote:
> 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> 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. >>> >> >>> 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. > -- 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.
