Thanks for the tip — that led me to these other relevant discussions: * https://groups.google.com/forum/#!searchin/golang-nuts/gohack$20replace$20modules * https://www.reddit.com/r/golang/comments/cvapcu/go_mod_how_to_get_it_to_find_packagesmodules_in/ * And now I understand the point of this tool: https://github.com/rogpeppe/gohack * And here’s a very helpful tutorial: https://dev.to/maelvls/why-is-go111module-everywhere-and-everything-about-go-modules-24k
(It is worth noting that the official blogs don’t really address this issue — I just looked for “replace” in these blogs and it isn’t discussed: https://blog.golang.org/v2-go-modules) The issue I’m having is well summarized from the reddit thread: > Eg. Say I’m developing a library and a program at once. If I make changes to > the library, I also need to upload it to its git repo so it downloads it. > Alternatively, I can use the redirect. But then when I commit it to git, I > then need to remove the redirect line, otherwise the user who downloads the > program source needs to manually download the other library. > It just makes development between two separate git repos really really > fucking hard. Before, I could just leave them In gopath and then I could edit > them both and work on them together. Then someone grabbing just the app would > just grab the dependency and it was done. Given the prevalence and advantages of splitting large projects into different libraries & packages, the extra difficulties in dealing with this situation seem like a real impediment (and gohack doesn’t really solve the problem it seems — more for minor hacking but not for full-scale parallel development across packages / repos). The current support for both GOPATH *and* modules seems like an ideal situation to me: there are two effective “branches” of the code (even without the extra hassle of git branches): the current GitHub code, and the tagged released versions with go.mod’s as needed for those releases. Anyone who needs a stable build gets the tagged release and gets their reliable build using modules. And the developers and bleeding edge folks can just live out of GOPATH as before. No need to remember to remove replace directives, etc — everyone’s happy (once you get past setting GO111MODULE appropriately)! So maybe it could just be left this way :) - Randy > On Feb 1, 2020, at 10:50 PM, Tamás Gulácsi <tgulacs...@gmail.com> wrote: > > See the "replace" directive of go.mod. > replace my/pkg => ../../my/other/pkg > Will use that other pkg instead of my/pkg. > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/9288880b-244f-4c5a-a188-c1a723ec8d76%40googlegroups.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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/FDA3AE68-8C9F-4D53-B731-EB2C39517462%40gmail.com.
