New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Changing import paths #3680
Comments
+1, all Pros are equally valid. |
+1 |
I think we will need This is the same as k8s (https://github.com/kubernetes/apimachinery). |
It is possible to implement, but if we do that we will only be able to have a custom import for cert-manager itself rather than anything in the org. Whether that's desirable is a different question. Following up from the stand-up this morning, it would be more sane to use go.cert-manager.io - if we used cert-manager.io we would have to create dummy pages on the website repo just to hold the go import metadata |
Imagining that we use For the top level import path: -github.com/cert-manager/cert-manager
+cert-manager.dev For example, with: curl cert-manager.dev The <html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<meta name="go-import" content="cert-manager.dev git https://github.com/cert-manager/cert-manager">
</head><body>
Nothing to see here! This page's meta is where the stuff is.
</body></html> For other projects in the -github.com/cert-manager/istio-csr
+cert-manager.dev/istio-csr or -github.com/cert-manager/website
+cert-manager.dev/website For example, with: curl cert-manager.dev/website The <html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<meta name="go-import" content="cert-manager.dev/website git https://github.com/cert-manager/website">
</head><body>
Nothing to see here! This page's meta is where the stuff is.
</body></html> Is that how we are imagining things to be? And even cooler, we could have some JS that does a redirection (since we cant use a
|
Ooops I forgot that, for example, if we have cert-manager.dev → github.com/cert-manager/cert-manager then there is an indetermination: cert-manager.dev/cmd → is it github.com/cert-manager/cert-manager/cmd # ❌
→ or is it github.com/cert-manager/cmd # ❌ So using either |
We discussed this in the public development meeting and decided to not go ahead with it. |
After a discussion in our stand-up, it was suggested that while we are moving repositories across to the cert-manager organisation we could rename our packages to include a vanity URL such as
cert-manager.io/cert-manager
Pros:
Cons:
cc @jetstack/team-cert-manager
The text was updated successfully, but these errors were encountered: