improve robustness of linking to license on hosting website #73
Comments
|
I noticed that problem 2 and 3 are mostly solved by pkgsite/source package. We will still need to leave this issue as open. |
|
Giving a breaking example for case 2 "support modules not at root": Note the URL https://github.com/googleapis/google-cloud-go/blob/storage/v1.10.0/storage/LICENSE is broken, the correct URL should be https://github.com/googleapis/google-cloud-go/blob/storage/v1.10.0/LICENSE. The problem is caused by the fact that:
Note, adopting pkgsite/source allowed us to get the correct tag |
|
Examples for problem 1: distinguishing "major branch" and "major subdirectory" conventions Major branch (result is correct)Major branch: a new major version is released in a branch, source code is at root of repo. Major subdirectory (incorrect)Major subdir: a new major version is released in a subdir in the same branch as v1, source code for v2 is at a subdir ./v2/ Therefore, root cause for this failure example is in fact the same as #73 (comment). The guessed URL is incorrect for module not at the root of a repo. |
|
Added a v2 proposal roadmap item: validate license URL by fetching it, we can detect these failures and turn the URL into unknown or try other locations again and finally verifying file content is exactly the same. With these workarounds, we can mitigate the issue of user unknowingly got an invalid URL. |
|
Furthermore, we can solve all above broken cases by:
|
|
Could you export a (versioned) URL to the root of the repo as well? I'm creating a licenses page in my web app and would like to link the package name to the respective github (or wherever) page. |
The csv format is fixed, I would not modify it.
Welcome a PR, this isn't too hard. |
|
Okies, already started and have it basically working - unfortunately I won't have time to polish/finish it this/next week, but will do when I get to it. |
resolves google#73, resolves google#186 For modules that are not at the root of the repo, Go will make a copy of the LICENSE file from the repo root into the module's directory when creating the .zip file (see https://go.dev/ref/mod#vcs-license) This throws off URL generation, as FileURL will create a link to a repo URL to the license that doesn't exist as the file was synthesized by Go. Attempt to detect this case by examining the zip file that Go creates - As it stands, it appends the LICENSE file to the zip's file directory; we can generally assume that if we see such an addition, it's a result of Go copying it there and therefore it's not a real file in the repo, instead being copied from the root. If we find that to be the case, generate a link to the original LICENSE file at the root of the repo instead. The complex e2e test here exercises this nicely (updated links didn't work before, now they do).
resolves google#73, resolves google#186 For modules that are not at the root of the repo, Go will make a copy of the LICENSE file from the repo root into the module's directory when creating the .zip file (see https://go.dev/ref/mod#vcs-license) This throws off URL generation, as FileURL will create a link to a repo URL to the license that doesn't exist as the file was synthesized by Go. Attempt to detect this case by examining the zip file that Go creates - As it stands, it appends the LICENSE file to the zip's file directory; we can generally assume that if we see such an addition, it's a result of Go copying it there and therefore it's not a real file in the repo, instead being copied from the root. If we find that to be the case, generate a link to the original LICENSE file at the root of the repo instead. The complex e2e test here exercises this nicely (updated links didn't work before, now they do).
In v2, I implemented some utils to get github repo from go-import=1 and use it to generate public & versioned links to detected licenses' hosting website (for now, only github).
I noticed some harder problems:
ROOT/autorest. https://github.com/googleapis/google-cloud-go/tree/master/storage is another example, tags for it has "storage/` prefix.Potential Solution
@wlynch pointed out the following references, there's an internal source package built for pkgsite that exactly provides a package that can figure out repo hosting website of a go import path and get a public link to source code. However, the package is internal, so we cannot directly import it.
I'll ask if they are ready to make it public, or I have to vendor it in some way.
EDIT: the reply is that we need to vendor it: golang/go#40477 (comment).
References
The text was updated successfully, but these errors were encountered: