Skip to content
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

Closed
jakexks opened this issue Feb 18, 2021 · 7 comments
Closed

RFC: Changing import paths #3680

jakexks opened this issue Feb 18, 2021 · 7 comments

Comments

@jakexks
Copy link
Member

jakexks commented Feb 18, 2021

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:

  • We have to rename the package anyway, so doing this "future-proofs" the project for moving in future.
  • Slightly shorter and more readable import path - many other projects are using it e.g. k8s.io, go.etcd.io
  • It looks cool 🙂

Cons:

cc @jetstack/team-cert-manager

@jakexks jakexks added this to To do in Github Organisation Move via automation Feb 18, 2021
@JoshVanL
Copy link
Collaborator

+1, all Pros are equally valid.

@irbekrm
Copy link
Collaborator

irbekrm commented Feb 18, 2021

+1
Is it possible to have the path just as cert-manager.io rather than cert-manager.io/cert-manager to make it shorter and avoid the repetition?
That also seems to be how k8s has it i.e k8s.io/apimachinery .

@JoshVanL
Copy link
Collaborator

I think we will need cert-manager.io/cert-manager. We have multiple projects under cert-manager.io e.g. cert-manager.io/istio-csr.

This is the same as k8s (https://github.com/kubernetes/apimachinery).

@jakexks
Copy link
Member Author

jakexks commented Feb 19, 2021

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

@maelvls
Copy link
Member

maelvls commented Feb 19, 2021

Imagining that we use go.cert-manager.io or we purchase the $12/y cert-manager.dev domain, here is how I understand things:

For the top level import path:

-github.com/cert-manager/cert-manager
+cert-manager.dev

For example, with:

curl cert-manager.dev

The go get tool would see:

<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 cert-manager org:

-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 go get tool would see:

<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 301 Redirect here) so that:

@maelvls
Copy link
Member

maelvls commented Feb 19, 2021

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 go.cert-manager.io/cert-manager or cert-manager.dev/cert-manager seems inevitable 😅

@jakexks jakexks moved this from To do to In progress in Github Organisation Move Feb 24, 2021
@jakexks
Copy link
Member Author

jakexks commented Feb 25, 2021

We discussed this in the public development meeting and decided to not go ahead with it.

@jakexks jakexks closed this as completed Feb 25, 2021
Github Organisation Move automation moved this from In progress to Done Feb 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

No branches or pull requests

4 participants