`go.mod.local` was one idea. Another idea is to have a sort of "publish local" semantics, where the go tool has support for something like <version>-devel tags, which override the <version> defined in go.mod. So then you would "publish" the next version to your local mod cache (just creating/updating the module of the special version), and the go tool would then make use of that.
On Friday, August 31, 2018 at 5:47:05 PM UTC-5, ohir wrote: > > On Sat, 01 Sep 2018 06:57:21 +0930 > Dan Kortschak <dan.ko...@adelaide.edu.au <javascript:>> wrote: > > > While this seems to be the correct way to do it, it also seems like a > > very obvious point of entry for human error. > > Looks like we need `go.mod.local` > ASAP. > > In many workplaces a mishap leak of internal paths to the outside, even > with > opensourced stuff can end someone's career. With current go.mod one would > need to **rewrite** go.mod on CI commit. > > > We have tooling to prevent incorrect commits of files using gitignore > > and hgingnore and yet people still accidentally commit files that > > should not end up in repositories. Now the situation exists where there > > is a file that is intended to be committed to the repository, but > > during development may need to have specific lines of it altered for > > development builds. > > > > The absence of good documentation for the modules workflow and apparent > > warts like this make the change to modules an unwelcoming experience > > for Go developers. > > -- > Wojciech S. Czarnecki > << ^oo^ >> OHIR-RIPE > -- 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.
