Closed psantos1113 closed 1 year ago
The go command may not have this information if it only communicates with a proxy. Additionally this information is not guaranteed to be stable over time since code host can change, or even available.
If people really want this, there could be a (likely third party) tool to work it out from the output of go list -m
. I've thought about it in the past, but not implemented it yet. Beware that, like @seankhliao says, it's a best-effort reconstruction since Go modules are decoupled from VCS servers/systems.
Nested or overlapping modules also make this reconstruction work much trickier than it might seem.
This doesn't seem viable to me. The default Go config is to use the proxy, which does not serve this information. Making go list -m -json do additional repo work would slow it down, to provide info that very few use cases need. As others noted, we have worked very hard to completely separate modules from the underlying repos.
Doing this in a separate package makes more sense. (It need not be a standard or golang.org/x package.)
The .info
files served by proxies could theoretically report this information (where they already record the original commit timestamp).
It would be somewhat analogous to the “downloaded on…” citations you sometimes see in research papers that cite websites: it would tell you where the proxy got its copy of the module from, but the module wouldn't necessarily still be available from that source.
I remember filing #44742 for having the info recorded in the .info
files
Is this resolved by the "Origin" JSON key added to the output of go list -json -m
(and go mod download -json
) in Go 1.19? (See #53644, CL 411397, https://pkg.go.dev/cmd/go#hdr-List_packages_or_modules, and https://github.com/golang/go/issues/44742#issuecomment-1210986778.)
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.)
When executing the command
go list -m -u -json all
having the root repository path and sub-module directory information would be useful in determining where exactly a module came from. This would help determining where it was downloaded from and what tag was used to get the correct version of the module to debug any issues related to the module. In the go module documentation there is the following example:If the module imports golang.org/x/mod you would think that it is downloading the module from
https://golang.org
exactly. Based on the result of the go-get query in the example, the repository where the module is downloaded from ishttps://go.googlesource.com/mod
This illustrates that the repository URL could be different.Since go already calculates the repository root path and the submodule directory to obtain modules internally within go, I am proposing two additional fields to be added to the module data. "RepositoryRootPath": "", "ModuleSubdirectory": ""
Always show the RepositoryRootPath for all modules when listing them. If the module is located in a subdirectory of the root repository, then add the ModuleSubdirectory to the output of the module.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I created a sample module that imports modules that are in a subdirectory of a root repository.
main.go
go.mod
What did you expect to see?
go list -m -u -json all
Output:What did you see instead?
go list -m -u -json all
go list -m -u -json all
Output