Doing so would obviate the need for creating the go.mod file in the pdf directory; but I'm unclear what other "problems" this might introduce.

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 replace rsc.io/pdf v0.1.1 => ./pdf would be able to made to work, but replace rsc.io/pdf v0.1.1 => ../pdf (parent directory) would fail when compiling the package.

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:
replace rsc.io/pdf v0.1.1 => $GOPATH/rsc.io/pdf .

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 vgo get instead of git clone to create the local copy?

I could see a reasonable argument for vgo get writing a go.mod automatically on the way down, although that has the somewhat unpleasant side effect of making the downloaded code not a pristine copy of the upstream source.

Each package needs to be able to compile on its own.

This was my initial feeling. But given Russ' comments in #25662 (comment) I didn't know whether adding go.mod files to what really is "old" code breaks other invariants. After all, the code referenced in $GOPATH/src/v/... does not have a go.mod file.

As a counter proposal

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?)

maybe make it possible to reference "old code" by referencing the GOPATH like:
replace rsc.io/pdf v0.1.1 => $GOPATH/rsc.io/pdf .

Interesting idea.

The reason for containing pdf within my module is as follows: I want it to be committed as part of the module code.

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 github.com/myitcv/pdf, then I would want to be able to run a vgo get command to say (in effect) vgo get rsc.io/pdf from github.com/myitcv/pdf. This might well be something we also want to support, but I think it ultimately boils down to the same problem.

@bcmills

I'm curious: do you have the same problem if you use vgo get instead of git clone to create the local copy?

I'm probably missing something obvious here, but would vgo get not place the code in $GOPATH/src/v/... as opposed to the local directory?

It's more likely that I'm the one missing something obvious. 🙂

The reason for containing pdf within my module is as follows: I want it to be committed as part of the module code.

I think if you are committing the code to your repo, then you might as well put in an internal folder and git it a go.mod file

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 $GOPATH/src/v/rsc.io/pdf@v0.1.1 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:

$ cat v0.1.1.mod
//vgo 0.0.4

module rsc.io/pdf
$ 

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

 echo rsc.io/pdf >go.mod
 vgo list ./...

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.

I think this answers the question in the issue title at least; closing.

I think this answers the question in the issue title at least; closing.

It absolutely does, thank you.