src/cmd is not an importable module. Where are you getting the error from?

src/cmd is not an importable module. Where are you getting the error from?

While I was writing the example I realized that the returned value is not an ImportMissingError object, but a serialized string in golang.org/x/tools/go/packages.Error.Msg.
In any case, the problem remains the same - to find this error I need to check strings that can change over time.

Suggested solution: add more detailed values ​​to packages.ErrorKind, including:

1. MissingError which will mean that the package is missing from the project (no required module provides package $PKG_PATH; to add it:\n\t\tgo get $PKG_PATH)
2. NotExistError which will mean that the package (no matter standard library or external) does not exist

Doesn't that mean you're just shifting the string matching into x/tools/go/packages ?

Suggested solution: add more detailed values ​​to packages.ErrorKind...

I don't think ErrorKind is the right place for this information; its purpose is to report which layer of the system produced the error: metadata, syntax, or types. (Of course, go list produces metadata by parsing package and import declarations.) A "missing package" error is thus a particular kind of metadata error.

I'm not sure I understand the distinction between MissingError and NotExistError either. Isn't it the case that if a "package...does not exist" then the "package is missing from the project"?

There is a related proposal to provide a public API to discriminate all the errors produced by the type checker. If that proposal advances, then it would make sense for the packages.Error struct to have another field (e.g. Code int) that describes the particular error message within the namespace established by the ErrorKind (so, for example, kind=TypeError and code=9 would mean internal/types/errors.InvalidInitCycle).

See:

• cmd/go: define error codes and use them to describe errors. #30134
• go/types, x/tools/gopls: improve the positioning of type checker errors #42290

Doesn't that mean you're just shifting the string matching into x/tools/go/packages ?

Yes, but it is easier to track in the x package than for all users of x/tools/go/packages. Also, when this package is merged into the main branch, it will be possible to use common constants.

An alternative option is more complex, but in my opinion more correct - it is to generate the ErrorKind value (or something from which it can be unambiguously obtained) on the go toolchain side and add it to the output of commands that use loaders

I'm not sure I understand the distinction between MissingError and NotExistError either. Isn't it the case that if a "package...does not exist" then the "package is missing from the project"?

MissingError for cases when the package exists at all, but is not in the project. In this case, when importing, compilation fails with this error

NotExistError is about the fact that the package does not exist at all. For example, go get makes an HTTP request to $GOPROXY and receives the status code 404. In the case of "direct", this can also be implemented at the level of requests to the VCS

"Not found" in the proxy (or a proxy) doesn't mean it doesn't exist at all. Perhaps the proxy is incomplete, or requires authentication before it reveals that a module exists. Trying to account for errors at this level of detail often devolves into a fractal of complexity. What about non-go build systems such as Bazel, Pants, and Buck? See also #30134 (comment). I am skeptical that this approach is worth pursuing.

I could be wrong, but it looks like proxy.golang.org returns 404 only if the package really doesn't exist. Although, of course, this is not required by the GOPROXY protocol

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)