The key point I just learned from #40276: "Vendor directories are not included in module zip files."
I found this surprising because -mod=vendor is now the default (here <https://golang.org/ref/mod#vendoring>) - therefore, I expected the vendor directory, if present in the source, always to be used unless explicitly disabled. It would be possible (although not a good idea) for someone to tweak their vendor directory contents directly, as an ad-hoc way of forking dependent packages. This would work fine for local checkout and build, but fail for "go install". Presumably they should import the code into a directory called something other than "vendor" in that case? I think it would be helpful to flag this up at https://golang.org/ref/mod#vendoring It might also be worth a mention at https://golang.org/ref/mod#zip-files that vendor directories are excluded from module zip files (although I wouldn't be reading that section if I was only interested in how vendoring works) On Friday, 6 August 2021 at 00:39:00 UTC+1 seank...@gmail.com wrote: > This is intentional and sort of covered by the statement that no module is > considered the main module (where replace directives and vendor dirs take > effect) > > https://github.com/golang/go/issues/40276 has some more context > > On Thursday, August 5, 2021 at 9:40:03 PM UTC+2 Konstantin Khomoutov wrote: > >> Hi! >> >> We have recently turned one of our internal Go projects into a Go module. >> The project was using vendoring and we intend to continue doing so - just >> rather with the natural support from `go mod` instead of govendor as >> before. >> >> An interesting issue came up when we've decided to try the recently added >> ability of `go install` to grab a named module and build an executable >> from >> it: we would expect that when we do >> >> $ go install an/module/import/path@latest >> >> the command would grab the module's source code (it's hosted by a GitLab >> instance, so we'd expect the source code to be `git clone`-d) and then >> behave >> as if one would clone the module's repository by hand and then run >> `go install` in the local clone's work tree - that is, we'd expect the >> command >> to actually make use of the vendored packages and not attempt to download >> anything except the source code of the specified module. >> >> Instead, the command appears to read the module's go.mod file and then >> download all the dependencies from the network - completely ignoring the >> "vendor" directory of the module. >> >> I have tried to locate a related issue in the bug tracker, but failed; >> [1] is the closest I was able to come up with, but it appears to not >> touch the >> very problem I have described. >> >> The documentation also does not seem to specify the expected behaviour. >> >> Hence my question is: is this a problem worth reporting/discussing or >> just an >> undocumented behaviour which is "by design"? >> >> My take on why this behaviour is confusing is that it makes `go install` >> behave differently when it's apparently told to do the same thing to the >> same >> module: >> >> - When I have the module's source code on my filesystem, and I run >> `go install` in that directory, the command uses the vendored >> dependencies, >> builds and installs the executable provided by the module. >> >> - When I run `go install import/path/of/that/module@revision` >> I expect the command to just add one extra step - fetch the module's >> source code and then run `go install` in the (temporary) directory >> with the fetched source code. >> >> 1. https://github.com/golang/go/issues/44841 >> >> -- 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/cc71c23c-9b20-4146-9c38-2c06763fc05cn%40googlegroups.com.
