It's unfortunate that the ImportPath field output from go list is not always an actual import path.

I think the orthogonal basis of these names is:

• import path (example.com/foo)
• package name (foo, foo.test, or foo_test)
• test variant (foo.test or none)

That gives:

• foo
  • {path: "example.com/foo", name: "foo"}
• foo.test
  • {path: "example.com/foo", name: "foo.test"}
• foo [foo.test]
  • {path: "example.com/foo", name: "foo", forTest: "foo.test"}
• foo_test [foo.test]
  • {path: "example.com/foo", name: "foo_test", forTest: "foo.test"}

I wonder if it would make sense to provide those as separate variables. (Perhaps TOOLEXEC_PACKAGE and TOOLEXEC_FOR_TEST?)

I have mixed feelings about your suggestion.

On one hand, I agree that ImportPath fields not being actual import paths is weird and surprising. I'd love to clean that up, too.

On the other hand, if you make that refactor, then go list -test -json loses unique fields by which to globally identify and index packages. Right now, ImportPath works because it includes all three components (original path + _test separation + test variant). I guess you could rely on the user's code to stitch together unique strings based on three fields (ImportPath + Name + ForTest), but that would be easy to get wrong.

Maybe simplify ImportPath in go list -json as per the above, and add another field like UniqueIdentifier that's not guaranteed to be a valid import path.

In any case, though, I think that's a separate cleanup that should happen for all of cmd/go at once. Right now, TOOLEXEC_IMPORTPATH mostly mirrors ImportPath, with the exception of the ForTest part, so I think we should just fix that.

To clarify, when I say "uniquely and globally identify a package", I mean within a single build list. For example, to build a map[string]Package out of go list -json -test -deps.

To be clear: I don't think we should change the contents of the ImportPath field reported by go list -json at this point. That seems much too invasive, even if it is defensibly correct.

(I wouldn't be opposed to adding a new field for the actual import path, though.)

Ah, gotcha, I may have misunderstood. Do you agree with just making TOOLEXEC_IMPORTPATH agree with go list -f {{.ImportPath}}? I can try to send a patch for that this cycle.

I don't object to other env vars like TOOLEXEC_PACKAGE or one for the actual import path, but those can always be added at a later time.

I'm not sure that I really understand what use-cases TOOLEXEC_IMPORTPATH was added to address, so I don't know whether making it agree with go list -f {{.ImportPath}} would be the right choice.

That said, I really don't like the behavior of go list -f {{.ImportPath}}, so I have a hard time thinking that changing anything else to agree with it would be the right direction. 😅

The use case is uniquely identifying a package. I use that to be able to locate it in the output of go list -json -test.

go list -f {{.ImportPath}} is weird, but it is unique. TOOLEXEC_IMPORTPATH is already not just a plain old import path, as I showed in the original post, as in the third case it prints foo_test instead of foo. So I do think the easiest option is to make the two align, even if it's confusing to call that string "import path" :)

The alternative is more env vars like TOOLEXEC_FOR_TEST, but then it's not clear how I can map "real import path + package name + for test" back into go list -json -test. At least, not until go list -json gains a "real import path" field.

We dicussed this with @rsc recently, and concluded:

• None of us really understand what TOOLEXEC_IMPORTPATH is for, and it's not currently documented.
• Given that, it seems fine to define TOOLEXEC_IMPORTPATH as equal to the ImportPath field from go list.
• The semantics of TOOLEXEC_IMPORTPATH need to be documented either way.

Great, thank you :) The unclear documentation is partly on me. I'll send a CL soon, also documenting how it works.

Change https://golang.org/cl/313770 mentions this issue: cmd/go: make TOOLEXEC_IMPORTPATH consistent with 'go list -f {{.ImportPath}}'