Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
x/vgo: should we allow replace for "old" code? #25739
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
Each package needs to be able to compile on its own. To do that it needs to know that the GOPATH looks like. Aside from a possible technical issue to overcome, mixing code without a module file (and thus without a understanding of where it is in GOPATH) and "new" code with a mod file seems like it would increase confusion. Probably
I suspect this would be a bad idea.
As a counter proposal, maybe make it possible to reference "old code" by referencing the GOPATH like:
edit: I'm not advancing the requirement of referencing old code, but if this does turn out to be an issue, I think the GOPATH ref might be a good alternative.
I'm curious: do you have the same problem if you use
I could see a reasonable argument for
This was my initial feeling. But given Russ' comments in #25662 (comment) I didn't know whether adding
Just to be clear, this is definitely a question, not a proposal. I'm just trying to understand how this "flow" is supported (unless others feel the use case is more an edge case?)
The reason for containing
The alternative would of course be for me to fork the repo, but then I think we're caught short again here. Because imagine I fork the repo to
The replacement line must point at a module. If you are preparing a module in a local file system directory, then part of preparing it is having a go.mod. In the future it will be common for your clone of someone's repo to bring in a go.mod. Until then, you need to make it. It is important to know what the replacement module believes its import path base is (the module path) as well as what its requirements are (which may differ from the original, and which will not be consulted anyway). For both these reasons the go.mod must be present and cannot simply be inferred.
Now, it's true that if you said to replace some other thing => rsc.io/pdf v0.1.1 then that would work even though the code in github.com/rsc/pdf at tag v0.1.1 has no go.mod file. But that's because the combination "rsc.io/pdf v0.1.1" is going through a resolution process that does in fact construct a synthetic go.mod file as best it can from the sources. But a plain directory full of files does not carry the same context.
Re invariants, it is fine to put a module line that says what the code in that directory believes that directory's import path to be. That's what vgo get is doing on download.
As for the auto-generated go.mod not being in the $GOPATHfirstname.lastname@example.org directory, that's true, it's not there. It's in $GOPATH/src/v/cache/rsc.io/pdf/@v/v0.1.1.mod instead. The unpacked source directory is a pristine copy of exactly what is in the zip file ($GOPATH/src/v/cache/rsc.io/pdf/@v/v0.1.1.zip), so that we can compute its hash and expect that hash to be never-changing. In contrast, the details of auto-generating a go.mod from a file tree do change, as we fix bugs and make the conversion more capable. If go.mod lived in that source directory, the hash would change as vgo did, which would not break go.modverify (soon to be go.sum) verification. Instead the mod is kept in the cache directory, alongside the zip file. You'll also notice that it has a comment at the top with a version number:
That version number indicates the version of the converter used to generate the mod file. (Really a made-up number, it didn't need to look like semver.) Each time we make a substantial change to the converter and need to invalidate old conversions, we can bump the number in the vgo source code, and it will treat all those cached files as stale and regenerate them from the original source trees.
Bringing things back to the ../pdf directory, it should suffice to do
which will page in whatever rsc.io/pdf needs (nothing, it turns out). I've been wondering about some kind of 'vgo initmod rsc.io/pdf' command but I'm relucant to put something there that will be under significant pressure to grow in scope without bound.