Hi Paul, On 9 September 2018 at 16:26, Paul Jolly <p...@myitcv.io> wrote:
> Hi Scott, > > > Yes I see that in terms of compatibility it "all works out", but it seems > > underspecified what should happen. > > Which bit do you think is underspecified? > Perhaps how to ensure a security patch is actually applied for module that depends on earlier versions of itself indefinitely might be one consideration worth specifying. Otherwise, I'm not sure to what extent the docs on swtch.com represent the authoritative intent behind the docs, as I can't find anywhere on golang.org that refers to cyclic module dependencies and how to deal with them, and it is unclear to what extent or whether Russ's work on swtch.com still constitute "the" current docs. > > To my mind the behaviour is very clearly defined, notwithstanding the > next point. > > > Also, although your experience reports are > > clearly presented and make sense, when I step back my own impression > > is: that's not simple. > > That's certainly true. But... > > > I'd rather be spending time coding than figuring out > > or worrying about chains of cyclic dependencies going back in time > indefinitely. > > As would I, but I think in some situations these cycles are > unavoidable, assuming you can't collapse the two modules down into one > (and in the GopherJS we can't). > You could use 3 (or more?) modules acyclicly, couldn't you? 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.
