Re: Connection-local login programs
Michael Albinus <[email protected]> Wed, 25 Mar 2026 17:05:24 +0100
| Newsgroups | gmane.emacs.tramp |
|---|---|
| Message-ID | <[email protected]> |
Eshel Yaron <[email protected]> writes: > Hello Michael, all, Hi Eshel, > I have a use case that I couldn't find a clean solution for, and I'm > wondering if Tramp could provide a nicer way to handle it. > > In Kubed[0], we define a Tramp method called "kubedv2", which uses > kubectl to interact with Kubernetes workloads, somewhat similarly to the > "kubernetes" method from tramp-container.el. Following a feature > request from a user, we want the "kubedv2" method to work in multi-hop > settings, in which the user uses Tramp to connect to some remote host, > say via ssh, and then from that remote host they invoke a Kubed command > that starts a two-hop Tramp connection using ssh for the first hop and > kubedv2 for the second. > > The difficulty is that on the remote host (the target of the ssh > connection), the user may need to specify a different kubectl executable > to use as the tramp-login-program. Kubed lets you specify which kubectl > to use through a user option kubed-kubectl-program, and we always use > the connection-local value of that variable so users can configure > different kubectl to use on different hosts, but that doesn't naturally > extend to our Tramp method, because the tramp-login-program is always > taken from the specific value we put in tramp-methods when "defining" > the method. > > Is there a better (or just more officially supported) approach that you > would recommend? All parameters specified by tramp-methods can be overwritten by connection properties, see (info "(tramp) Predefined connection information") In your case, you could do (untested) --8<---------------cut here---------------start------------->8--- (add-to-list 'tramp-connection-properties (list "^/kubedv2:user@example\\.com:") "login-program" "/another/kubectl")) --8<---------------cut here---------------end--------------->8--- > Thanks, > > Eshel Best regards, Michael.