It isn't clear to me when or why this would have changed, but I think the reported Go 1.20 behavior of go/build is correct.

• (*Context).Import requests package data for a package import path, not a directory.

• Given the possibility of nested module paths, the lack of .go source files in a directory does not necessarily imply that the package does not exist (although that is often the case).

• With -mod=vendor, we cannot load the full module graph to check whether it contains another module that provides the package. (For example, in this case the package could be provided by a module with the path knative.dev, or one with the path knative.dev/eventing/pkg.) For that matter, even if we could load the full module graph, we can't say anything definitive about an import path that it doesn't contain.

FWIW - I can add a doc.go file as a work around to fix this.

Given the possibility of nested module paths, the lack of .go source files in a directory does not necessarily imply that the package does not exist (although that is often the case).

Can you clarify this point? Are you saying that because knative.dev/eventing/pkg/apis does not contain go code there could be some nested module that declares that a module at a parent path. So the module name/path doesn't match the actual location in the repo?

ie. moduleA - go.mod declares it's package as knative.dev/eventing/pkg/apis

go.mod
pkg/apis/
- moduleA/go.mod

For example, in this case the package could be provided by a module with the path knative.dev, or one with the path knative.dev/eventing/pkg

Likewise - I don't really understand. My assumption is a go.mod file at knative.dev/eventing would take ownership of all directories under knative.dev/eventing/* unless another module specified something more specific ie. knative.dev/eventing/moduleB - is that a bad assumption?

Probably also worth calling out is that a lot of modules don't have *.go files at all the intermediate levels in a path. It was never the case beforehand.

ie.

moduleA/
- go.mod
- some/path/
   - some-file.go

ie. empirical examples
https://github.com/kubernetes/client-go/tree/master/util
https://github.com/knative/networking/tree/main/pkg/apis

Should they be adding these empty files now?

Are you saying that because knative.dev/eventing/pkg/apis does not contain go code there could be some nested module that declares that a module at a parent path.

Yes. You could have a module structured like:

-- go.mod --
module knative.dev
go 1.20
-- eventing/pkg/apis/apis.go --
package apis

Or like:

-- go.mod --
module knative.dev/eventing/pkg
go 1.20
-- apis/apis.go --
package apis

In that example wouldn't you assume knative.dev/eventing/pkg is part of the same module in both cases - hence NoGoError might be the right value to return?

Should they be adding these empty files now?

No. I think you are conflating modules and packages?

A module is “a collection of packages that are released, versioned, and distributed together.”
A package “is constructed from one or more source files….”

In this case, the module is knative.dev/eventing. It contains packages like knative.dev/eventing/pkg/apis/config and knative.dev/eventing/pkg/apis/eventing. It does not contain packages knative.dev/eventing/pkg or knative.dev/eventing/pkg/apis, because those directories within the module do not contain source files. They can't be imported by other Go packages or programs, can't be built by go build, and so on.

However, the fact that they do not exist in the current module does not imply that they don't exist in some other module.

(*go/build.Context).Import imports packages — not modules or directories.

In contrast, ImportDir does import directories, and I would expect it to return a NoGoError in this case (but I haven't tested, and of course bugs are possible).

OK that clears things up - looks like ImportDir returns NoGoError

Thanks for all the clarifying answers.