Re: tramp (2.6.0.29.1 nil/nil); tramp-sh-handle-get-home-directory should handle user name better

[Warren Lynn]

Thanks for explaining the rationale behind all of this. Right now the hack of overriding " tramp-sh-handle-get-home-directory " works for my current need, so I will take that path for now (that's why we all love Emacs, right? :-) )

It will take me some time to play with the new k8 method in Emacs 29 tramp. One thing that hooked me to "kubel" (despite its deficiency and the need of my adding my own hacks on both tramp and that package itself) is it provides more than just a tramp remote access scheme. It can show logs, check resources, etc. It manages the pods. I am not sure that kind of functionalities are (or should) be in the scope of tramp itself. So ideally I would like to have a solid basic tramp naming/access scheme for k8, and another package on top of it for pod management.

Warren

On Tue, Jun 20, 2023 at 11:14 AM Michael Albinus <michael.albinus@gmx.de> wrote:

Warren Lynn <wrn.lynn@gmail.com> writes:

Hi Warren,

> But regarding the concept of "user" and "home directory", I have some
> different opinions.
>
> 1. I support the idea of expanding the tramp syntax so it can cover
> wider cases, such as k8 namespace (or even context?) mentioned in your
> email. As much as I like kubel, it is a bit of a pain that only one
> name space can be used at one time.

Great. So let's continue this discussion in another thread. Perhaps you
comment on bug#59797? It is about name spaces, but I believe it should
cover also container names.

> 2. However, that should not prevent us from handling the existing
> syntax better

"Better" is in the eye of beholder. I regard it as misuse.

> 3. "The point is, that in kubel the Tramp user is misused to be the
> (optional) container name.". We certainly can say that. But on the
> other hand, I think we also can ask: do we need to restrict the "user"
> part of the tramp syntax to an actual user name whose "echo ~
> <user_name>" must produce a valid home directory? What is the benefit
> of having that restriction? Do we gain anything by NOT returning the
> correct home directory simply for the sake of maintaining a "pure"
> definition of the "user" part of the tramp file syntax?

Tramp has evolved. The concept of "user" and "home directory" is used
also for other Tramp backends but only tramp-sh.el. Due to this, I'm
really opposed to apply hacks in mainstream Tramp which try to do
something different. It will break other Tramp parts for sure, and we
would fight with unforeseen problems we have added due to this. Believe
me, long term it doesn't pay to add hacks.

> 4. Even if for certain reasons (existing code, for example), changing
> the definition of "user" part in a tramp file name is not desired or
> practical (so we maintain the objection to the syntax "kubel" uses),
> we may still separate how the home directory is retrieved from the
> user itself. That's what Emacs 26.3 did (hence I noticed this
> "regression" while upgrading Emacs). It retrieves the home directory
> by sending "cd; pwd" to the shell process of the tramp connection.

This is easy. If you want to continue to use the user slot of Tramp file
names for something different in your package, under the hood (maybe
temporarily only, until you have applied the proposed syntax change),
you could override the existing `tramp-sh-handle-get-home-directory'
function. Like this:

--8<---------------cut here---------------start------------->8---
(defun my-get-home-directory (vec &optional _user)
  (when (tramp-send-command-and-check vec "cd && pwd")
    (with-current-buffer (tramp-get-buffer vec)
      (goto-char (point-min))
      (buffer-substring (point) (line-end-position)))))

(add-function
  :override (symbol-function #'tramp-sh-handle-get-home-directory)
  #'my-get-home-directory)
--8<---------------cut here---------------end--------------->8---

> I am speaking from the perspective of a regular user who does not
> really know the internals and history of tramp well, so I may well
> have missed some important design principles that invalidate my above
> points. But maybe an outsider sometimes can also give some fresh
> viewpoints? :-)

Definitely! And I count on you to improve Tramp's integration of kubernetes.

> Best regards.
>
> Warren

Best regards, Michael.