Add vanity-imports for modules we migrate to monorepo. #424
Conversation
|
I've tested this locally (with localhost.localdomain instead of podman.io). |
static/go/index.html
Outdated
There was a problem hiding this comment.
Do we need this file as well? I don't think we want the top level path to be used as module or maybe I missing something about the the go vanity URL's?
There was a problem hiding this comment.
We need it. You can check it in the https://pkg.go.dev/cmd/go@master#hdr-Remote_import_paths.
The import-prefix is the import path corresponding to the repository root. It must be a prefix or an exact match of the package being fetched with "go get". If it's not an exact match, another http request is made at the prefix to verify the tags match.
Note the "If it's not an exact match" part.
|
Might be worth to link https://pkg.go.dev/cmd/go@master#hdr-Remote_import_paths for the proper docs one the format |
In case we use just a prefix in the
In case we would use But maybe someone else would have some clever idea how to do it. |
jankaluza
force-pushed
the
vanity-imports
branch
from
00d56d4 to
67cea4d
Compare
Do you mean in the commit message or somewhere in the html...? |
commit messsage |
This commit adds new static .html pages which contain the metadata for go vanity imports: - https://pkg.go.dev/cmd/go@master#hdr-Remote_import_paths This allows us to use for example `podman.io/go/storage` in the go.mod. Go then does HTTP query to `podman.io/go/storage` followed by the HTTP query to `podman.io/go` to find out the real URL for git repository. If real person opens that URL in a browser, they are redirected to source-code for each module. Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
jankaluza
force-pushed
the
vanity-imports
branch
from
67cea4d to
464029d
Compare
Well that is a technical problem we can most likely solve somehow. Once we commit to import paths they are locked in and updating them requires large churn for our consumers so need to avoid that as much as possible. So I rather spend some time on nicer import names but we can discus it as team what names should be used. Also I should point out that using podman.io is a bit in conflict with CNCF ownership as the common/image/storage repos have not been transferred to CNCF. The podman.io domain is now owned by CNCF as they control repo imports we have not transferred? Maybe it doesn't matter since we like to combine everything so the libraries should becomes part of CNCF eventually as well. Lastly, these vanity imports are quite critical and security sensitive, anyone who has control over the domain or webserver could point to different code which can comprise all people using these. So personally I am not sure sharing access here with the main site which is made up of of a ton of javascript is the best thing either. Not to mention that more people have write access here than the main code repos. |
|
We could probably handle go-get=1 in the react page and serve that static file instead of the real generated page. Or maybe just redirect. I will give it a try. |
|
Hm, but it depends how podman.io is deployed. /me goes rtm |
|
We've discussed this on a call and instead of this approach, we will introduce new go.podman.io subdomain served by github-pages in containers/go.podman.io project. The PR for this is here: containers/go.podman.io#1. I'm going to close this PR without merging. |
This commit adds new static .html pages which contain the metadata for go vanity imports.
This allows us to use for example
podman.io/go/storagein the go.mod. Go then does HTTP query topodman.io/go/storagefollowed by the HTTP query topodman.io/goto find out the real URL for git repository.If real person opens that URL in a browser, they are redirected to podman.io.