Thoughts on a common lib repeated functions?

[dylanhitt]

This is done a lot

home, err := os.UserHomeDir()
if err != nil {
    panic(err)
}

cfg, err := clientcmd.BuildConfigFromFlags("", path.Join(home, ".kube/config"))
if err != nil {
    panic(err.Error())
}

client := kubernetes.NewForConfigOrDie(cfg)
desired := corev1.ConfigMap{
    ObjectMeta: metav1.ObjectMeta{
        Name:      name,
        Namespace: namespace,
    },
    Data: map[string]string{"foo": "bar"},
}

Thoughts on a pkg/common or common/ or . I thin it will help better focus on the example that's trying to be displayed rather than the setup.

[iximiuz]

That's a great question!

I've been asking it myself since the inception of this project. As always, there are pros and cons. The biggest pro will be the reduced code duplication. However, the con is quite significant - to understand a single mini-program, one would need to learn the common package too. And this kind of against the main idea of this project - it was supposed to be a collection of pure independent mini-programs that rely only on the k8s and related packages without introducing extra abstractions and ready to be copy/pasted to someone else's code.

TL;DR I intentionally decided in favor of code duplication. However, I'm ready to reconsider, provided some good arguments.

[dylanhitt]

That is fair. When you put it that way I don't really have a great pro. I typically clone code when I look at it so navigating packages is fairly straightforward.

That being said it seems you've thought on this. I will close. Thanks for the response

[iximiuz]

The thing is that this project is not a one big Go library but a collection of small(er) independent Go (mini-)programs. Extracting the common functionality would introduce a dependency for every mini-program on the common library. And that could complicate reading the code and especially reusing it in other projects. Instead of just copying the content of one file, you'd need to find a way to take the needed part of the common logic too.