Background

In our company, we're using a (git) monorepo to host all our code and dependencies. Currently, we're keeping it in a _vendor/ subdirectory, which was created before vendor/ became canonical. We kept it so mainly because of #19090, and because we had our in-house vendoring tool (created long ago) which serves us well enough. Since #19090 was closed, we were open to migrate (our vendoring tool) to the canonical vendor/ path (and maybe even to some more popular tool), and at this point the only thing stopping us was inertia and not enough internal resources.

Being in this position, I'm quite interested in following the vgo story for our company. It seems to have many characteristics which sound attractive in our use case, esp. the conservative approach to version upgrading, and stated interest in build reproducibility.

However, after reading all the relevant articles from rsc published till now, I don't see how we could use vgo in its current shape in our monorepo scenario. Please note we still have code from code.google.com in our repository; I remember that lesson (from even before leftpad became a meme) very lively. I understand that the vgo articles hint at some proxy/caching solution for this concern. I've seen mention of the GOPROXY=file://... feature. I understand from this that we could potentially store .zip files + some metadata in our monorepo, and with the above GOPROXY feature, should be able to use our pinned copies of our dependencies. However, at this point it feels very weird to me to not be able to easily inspect the source code of the libraries, given that they'd have to be stored in zips, IIUC.

Proposal

So at this point, after I've tried to explain my background and situation, I'd like to ask and propose: could you consider going one step further, and supporting GOPROXY-like feature that could be pointed at "unzipped" source code of dependency packages/modules, e.g. in case they're stored in a monorepo? In other words, something more or less like: GOPROXY=file://$GOPATH/vendor (in our particular case, more like GOPROXY=file://$GOPATH/our/package/root/_vendor/src). And by the way, isn't this in fact more or less how third-party dependencies are stored in a monorepo in Google? I'd imagine it would be good for vgo to support a Google-like scenario?