go imports aliases

[ameteiko]

👋 go imports aliases

Hello Jellies, let's brainstorm the unification of the aliases for our imports.

RFC

Package	Proposed alias	Refined alias
github.com/cert-manager/cert-manager/pkg/apis/certmanager/v1	certmanager
github.com/cert-manager/cert-manager/pkg/apis/meta/v1	certmanagermeta
github.com/google/go-containerregistry/pkg/v1	containerregistry
github.com/kyma-project/lifecycle-manager/internal/declarative/v2	declarative
github.com/kyma-project/lifecycle-manager/internal/declarative/v2/test/v1	declarativetest
github.com/kyma-project/runtime-watcher/listener/pkg/event	watcherevent	listenerevent
github.com/kyma-project/runtime-watcher/listener/pkg/metrics	watchermetrics	listenermetrics
github.com/open-component-model/ocm/pkg/contexts/ocm/compdesc/meta/v1	ocmmeta
github.com/open-component-model/ocm/pkg/contexts/ocm/compdesc/versions/v2	compdescv2
istio.io/api/networking/v1beta1	istioapi
istio.io/client-go/pkg/apis/networking/v1beta1	istioclientapi
istio.io/client-go/pkg/clientset/versioned	istioclient
istio.io/client-go/pkg/clientset/versioned/scheme	istioscheme
k8s.io/api/admission/v1	apiadmission
k8s.io/api/admissionregistration/v1	admissionregistration
k8s.io/api/apps/v1	apiapps
k8s.io/api/core/v1	apicore
k8s.io/api/rbac/v1	apirbac
k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1	apiextensions
k8s.io/apimachinery/pkg/api/errors	apierrors
k8s.io/apimachinery/pkg/apis/meta/v1	apimachinerymeta	apimeta
k8s.io/apimachinery/pkg/labels	k8slabels
k8s.io/apimachinery/pkg/runtime	machineryruntime
k8s.io/apimachinery/pkg/util/runtime	machineryutilruntime
k8s.io/apimachinery/pkg/util/yaml	machineryaml
k8s.io/client-go/kubernetes/scheme	k8sclientscheme
sigs.k8s.io/controller-runtime	ctrl
sigs.k8s.io/controller-runtime/pkg/controller	ctrlruntime
sigs.k8s.io/controller-runtime/pkg/log	logf
sigs.k8s.io/controller-runtime/pkg/metrics	ctrlmetrics
sigs.k8s.io/controller-runtime/pkg/metrics/server	metricsserver

Please post your ideas and concerns in comments

[nesmabadr]

Thanks Oleksandr!

I have some suggestions here:

• github.com/open-component-model/ocm/pkg/contexts/ocm/compdesc/versions/v2 => (for consistency, I suggest removing the v2 from the alias so "compdesc")
• github.com/kyma-project/runtime-watcher/listener/pkg/event => listenerevent
• github.com/kyma-project/runtime-watcher/listener/pkg/metrics => listenermetrics
• k8s.io/apimachinery/pkg/apis/meta/v1 => apimeta

[ameteiko]

Regarding the compdescv2 -> compdesc renaming, I thought of it until I found this file:

lifecycle-manager/pkg/testutils/builder/moduletemplate.go

Line 10 in d7a2428

"github.com/open-component-model/ocm/pkg/contexts/ocm/compdesc"

lifecycle-manager/pkg/testutils/builder/moduletemplate.go

Line 12 in d7a2428

compdesc2 "github.com/open-component-model/ocm/pkg/contexts/ocm/compdesc/versions/v2"

It uses the compdesc package of both versions, that is why this is the only one I left with a version suffix.

[ruanxin]

version suffix is required for some case, this one actually a good example, ocm have schema version 2 and version 3alpha1, here we are specifically import code used for version 2

[ruanxin]

k8s related api package, the version is required, it's a naming convention, also brings the value. different versions might bring breaking changes, that's the API rule defined by k8s. To deal with it, sometimes we need to support different versions even.

So k8s.io/* package should have version suffix to indicate which API version LM consumes.

e.g:
k8s.io/api/apps/v1 => appsV1
k8s.io/apimachinery/pkg/apis/meta/v1 => apimetaV1
k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1 => apiextensionsV1

[ruanxin]

Actually, other packages should also follow API rule defined by k8s, so the version suffix can't be omitted.

for instance: "istio.io/api/networking/v1beta1" is a good example, if you look at the current API version, it support both v1alpha3 and v1beta1, when we import the API, we need to know which API contract to follow with.

[ameteiko]

@ruanxin, for this we'll have:

Package	Proposed alias	Refined alias
k8s.io/api/admission/v1	apiadmission	apiadmissionv1
k8s.io/api/admissionregistration/v1	admissionregistration	admissionregistrationv1
k8s.io/api/apps/v1	apiapps	apiappsv1
k8s.io/api/core/v1	apicore	apicorev1
k8s.io/api/rbac/v1	apirbac	apirbacv1
k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1	apiextensions	apiextensionsv1
k8s.io/apimachinery/pkg/api/errors	apierrors
k8s.io/apimachinery/pkg/apis/meta/v1	apimachinerymeta	apimetav1
k8s.io/apimachinery/pkg/labels	k8slabels
k8s.io/apimachinery/pkg/runtime	machineryruntime
k8s.io/apimachinery/pkg/util/runtime	machineryutilruntime
k8s.io/apimachinery/pkg/util/yaml	machineryaml
k8s.io/client-go/kubernetes/scheme	k8sclientscheme

As you can see all currently used versions are v1 (the stable ones), so I see no benefit from including the version suffix into the alias.

When we need to introduce a new dependency's version (let's assume it is k8s.io/api/admissionregistration/v1) then we can introduce a new alias apiadmissionv2 for the transition period while (and if) we'll be supporting two versions.