Eval instead of new shell?

[JohnPolansky]

So first off may I just say wow your tool is awesome and you've put a lot of attention into it. I've already switched over to using it and trying to get my colleagues on it too being able to work multiple clusters is a must for my daily work so this has been amazing.

I was curious as to why you are creating a new shell whenever you switch to the new K8 cluster. I admit I haven't had time to fully dig through your code, but it seems like you are using a combination of new kubeconfig files stored in temp directories and environment variables to allow multiple clusters in different terminal windows, which is really cool idea.

However I was wondering why open a new shell, for me the additional shell adds a significant "switch" time to the process and I'm not clear why as just starting a new zsh doesn't take as long. I was curious what if creating a new shell you use kubie to copy and create the new kube-config files like you do, but instead of opening a new shell with environment variables, when if you output those environment variables when you exit your app. Then use an eval call to execute the commands.

For example something like this:

function kubie() {
   25    eval $(cd /opt/tools/kubie ; kubie $@)
   26  }

When your app exits it outputs export KUBE_CONFIG=/tmp/path/file and the eval would trigger and set the values within the current shell, then any new execution of a new cluster switch would delete the previous files/create new ones.

I realize using the function eval call is a bit weird, but I've used it for some small tools I've used with great success, but I was curious if there were specific reasons why you wanted to spawn a new shell.

Thanks again great tool, just curious to understand better. :)

[valorl]

There could also just be a special flag on the commands that normally spawn a shell, that you can set in order to not spawn a shell and instead output the shell command. That way both modes are supported. The flag could be --mode=(shell|eval) maybe. I haven't dived into the code either, but there's probably some additional work needed (e.g. ns seems to expect nesting).

Also, maybe a benefit of the shell is that the lifetime of the new shell defines a scope for the temp file, which you can delete once the shell exits. With just eval in the root shell, it sounds harder to figure out when the kubeconfig isn't used anymore.

[reegnz]

I would also welcome it if you could just have kubie generate a temp. kubeconfig, and expose it's location and allow the handling of the shell integration by other tools. It would enable seamless integration with other shell tools like https://github.com/direnv/direnv. Only thing needed for that would be for kubie to print the export KUBECONFIG=/tmp/path/file so one can source it (as described above), or just printing the tmp file location.

TBQH I wouldn't care for kubie to know how long I use the kubeconfig, as I'd just use it to generate one given my direnv context. I would want my context to activate on directory switches, not necessarily explicit kubie calls.

[valorl]

I've also started seeing value in avoiding nested sessions and I personally moved to https://github.com/danielfoehrKn/kubeswitch for this reason.