Hi Guy, Right now, my understanding is there is not a perfect answer to your questions.
However, these are very important questions, including I think community discussion right now can help establish alternative immediate solutions, as well as help shape how things might work in 1.12 and beyond. If you haven't already, I would suggest reviewing this thread here: https://gophers.slack.com/archives/C9BMAAFFB/p1537968235000100 That thread includes comments on some possible current options, some community tooling that might help, some comments on how one-off tools or commit hooks might be put together on top of things like 'go mod edit -json', etc. (That thread also includes a summary of some of the live discussion issues in the tracker on these topics). You might then want to comment in that thread (or in this thread) with a bit more on what might or might not work for you, ideally including some comments like "gohack doesn't help in our case because X", or "go mod edit doesn't help us because Y", or "frequent use of semver pre-release tags doesn't help us because Z". Or maybe you will post "Our solution is A and B". Also, towards the end of your post in this thread, you are touching briefly on some questions of sequencing, and the ordering for publishing two modules if one module depends on an update in the other module. A brief comment on that -- one general property of the modules system is 100% reproducible builds using the information in 'go.mod'. One example of this is if someone has published module A and module B, and A has a 'require B v1.2.0', then A will continue to have 100% reproducible builds even if a newer v1.3.0 of B is later published. An implication of this is that you can safely publish an update to B without breaking A's build, and then later publish an update to A that requires the newer B. You can read a bit more about that in the "High Fidelity Builds" section of the official proposal ( https://github.com/golang/proposal/blob/master/design/24301-versioned-go.md#update-timing--high-fidelity-builds). That might or might not help in your situation, but wanted to at least mention this more general behavior. In any event, I would encourage you to post more on your topics below, including because community discussion on these multi-module workflows I think are an important aspect of working through the current possible approaches and how the tooling could or should be tweaked in the future. Best, --thepudds On Thursday, October 11, 2018 at 11:31:20 AM UTC-4, Guy Brandwine wrote: > > We are trying to use Go-Modules > > > > We have reusable repo : "github/mycompany/funcs" many repo's use this, > example : "github/mycompany/eCom/basket.go" > > > > A new ticket says : "basket should support export to xls" . > > In order to do that, we want to : > > 1. Add funcs.go a function "StructToXls(interface{})" > > 2. basket.go should use funcs.StructToXls(myBasket) > > > > in the current modules format we need to, push and TAG of funcs and then > update github/mycompany/eCom dependencies. > > > > If we have a small bug we would need to repeatedly push and tag funcs, > update eCom etc. > > > > Is there a better way (other than go.mod -> replace which is dangerous and > "developer must remember to use it everytime he changes a basic repo") to > work locally and when all done push and TAG the 2 repos ? > > Moreover, in our current process (git flow style with some modifications) > the developer only pushes the code to a branch, whereas the TL, approves > and merges the code. > > If the developer tags the library (funcs) locally and does not push that > (theoretically its not his duty neither he is permitted to do that), that > may create a false dependency, moreover, two different developer may do > diff changes in funcs both changing ver from 1.2.3 => 1.2.4 since the > increment is not centralized (which BTW needs a better tooling anyhow than > manually inc.). > > > > A better suggested flow would be greatly appreciated. > > > > -- 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.
