> Is it by design that these two commands ['go mod tidy' and 'go mod vendor'] are unstable like that?
That is more or less by design, but the behavior has evolved over time and it may be worth revisiting. This was discussed in #29058 <https://github.com/golang/go/issues/29058>. The rationale was that because 'go mod vendor' deletes and rebuilds the entire vendor directory, it would be dangerous to do that implicitly inside another command like 'go mod tidy', since people frequently make local changes to vendor, like when preparing a patch for upstream. That discussion was a couple years ago, before vendoring was enabled automatically. At the time, you had to specify -mod=vendor with build commands. A better user experience might be 1) support for incremental changes to the vendor directory via 'go get', 'go mod tidy', 2) detection of local changes to the vendor directory so we can avoid overwriting them. I've opened #45161 <https://github.com/golang/go/issues/45161> to restart that discussion. > This tool in particular seems to try to read a DB file from a subdir of the directory its source code came from (as per `runtime.Caller(0)`) which ...doesn't work at all with vendoring, since the dir doesn't contain Go code. > AFAIK there's not a way to ask `go mod vendor` to include the whole repo is there? I can't find a spec for modules.txt - it would be super cool if I could add some tag in there... As it stands, all this was for naught. Is there another way to include and locate that file? Even if it were vendored, runtime.Caller(0) may be unreliable when -trimpath is used, and the files will be read-only in the module cache when vendoring is not used. 'go mod vendor' only pulls in directories for packages needed to build packages in the main module and their tests ('go list -test -deps ./...', essentially). I don't think we even include testdata or packages imported by those packages' tests. We don't have a spec for vendor/modules.txt. it basically contains enough information for the go command to know which packages are vendored and which modules they came from. On Sat, Mar 20, 2021 at 12:47 PM Manlio Perillo <manlio.peri...@gmail.com> wrote: > Il giorno venerdì 19 marzo 2021 alle 23:20:49 UTC+1 Tim Hockin ha scritto: > >> Thanks for feedback, comments below >> >> On Thu, Mar 18, 2021 at 3:35 PM Jay Conrod <jayc...@google.com> wrote: >> >>> >>> > [...] > >> >> >>> *2. "writing go.mod cache" error messages* >>> >>> This error message should be a lot better. Sorry about that. >>> >> >> I mean, "mkdir /home/thockin/go: not a directory" is pretty concise - >> it's not a directory (on purpose) because I really don't want Go randomly >> deciding to write stuff to my homedir (which I suspected was happening, and >> that's why I made it a non-directory :) >> >> > > If you don't want the go tool to write files to your home directory, you > can just define a custom GOPATH or GOMODCACHE. As an example, on my > sysytem I have set GOPATH to ~/.local/lib/go, and this directory is > excluded from the backup. > > Manlio > > -- > 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/8002edf8-1a9e-44a6-a427-3fbc2b4e1dc1n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/8002edf8-1a9e-44a6-a427-3fbc2b4e1dc1n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAGCADbYLzKJi7AYdgzyJmm4WHHe4GWgQ%3DseFfxLPOLmpL5Bg3w%40mail.gmail.com.
