@jdstrand Thank you so much for the clarifications on this and for taking the time to respond! So I have a few issues with this which I think warrants for a classic confinement.
- Taking a kubectl dependency with the k9s snap means I have now to maintain a different release cycle to ensure an up to date deployment as kubectl revs.
- This also means that the user might choose to run a different version of kubectl on their system and yet be confined to the one the ships with K9s while in K9s. This doesn’t sit right with my expectations.
- K9s currently needs access to /tmp, .k9s, .kube and $PATH. Kubectl is one of the execs but we also launch a user preferred editor which per your explanation will mean, K9s needs to ship with these snaps too? An impossible requirement.
- I understand the link of the k9s snap home to current, but all dots files dependency must remain stable while the K9s tool revs. Hence linking to the `current release directory would require additional symlinks for the .dotfiles.
- Additionally the tmp dir is buried under the snap home and not as advertised as /tmp by the CLI. So that does mean that I would need to rewrite parts of the code whether a snap release is at play or not. Which is one of the thing I was trying to avoid in the first place.
So do I have enough here to make the case to request a classic confinement. I love Snapcraft and would love my users to experience K9s/Popeye in their best light without have to muck too much with configuration and settings ie snap install and go. I hope these make sense to your team and that your guys feel there is enough here to warrant a classic confinement.
Thank you for your time, patience and consideration!