Subject: bug#76955: 30.1; php-ts-mode-php-executable default path may not match remote path

From: Morgan Willcock <[email-masked]>
Date: Sat, 15 Mar 2025 15:03:57 +0000

Eli Zaretskii <[email-masked]> writes:

>> From: Morgan Willcock <[email-masked]>
>> Cc: [email-masked],  [email-masked]
>> Date: Sat, 15 Mar 2025 13:07:54 +0000
>>
>> Eli Zaretskii <[email-masked]> writes:
>>
>> >> From: Morgan Willcock <[email-masked]>
>> >> Cc: Vincenzo Pupillo <[email-masked]>,  [email-masked]
>> >> Date: Sat, 15 Mar 2025 11:03:40 +0000
>> >>
>> >> Eli Zaretskii <[email-masked]> writes:
>> >>
>> >> > So I conclude that expecting "php" to be on PATH on remote systems is
>> >> > a requirement, since nothing else will work reliably enough, and let's
>> >> > close this discussion at that.
>> >>
>> >> I am not sure what you mean by "reliably", but being on PATH is not a
>> >> requirement to use it.  It will very likely be on PATH, but with some
>> >> additional configuration of the TRAMP connection it doesn't need to be.
>> >
>> > I mean that we should use executable-find for remote directories,
>> > thus assuming that the program is on PATH on remote systems, and let
>> > users customize the local value via the user option.
>>
>> I think this introduces an additional complication if executable-find
>> finds a binary which is not the one that should be used.
>>
>> > IOW, the user option should not have effect on remote invocations.
>>
>> >From my perspective as a user of mode, just setting the value to "php"
>> introduces no additional complexity, works in more places by default
>> than the current value, and doesn't deviate from how other modes (and
>> associated executable paths) are managed.
>
> My suggestion will still work in your case, no?

It would work in my particular case, but it also means that someone who
installed their own executable at "~/bin/php" on both the local and
remote systems, and then customised the value to "~/bin/php", would now
have a new class of problem on the remote system.

> The advantage is that it will also work in other cases, when the user
> option is customized to name a local version of the php executable.

These same issues exist with LSP server binaries for Eglot and linter
executables for Flymake; the defaults assume they are on PATH, but there
is also the possibility that someone has had to get the required binary
themselves, without installing it system-wide, and the TRAMP settings
for the connection are what allows the search to be steered to the
correct place.

I don't think it is feasible to begin a precedent that any code which
attempts to run an executable should now explicitly check whether the
system is remote and assume that it knows better than the user's
configuration.  I don't know the codebase well enough to declare that
there are no other instances of this happening, but I can show a similar
problem:

  (setq find-program "c:/ezwinports/bin/find.exe")

Having set this value, I have now broken the ability to use find on any
remote system where this path doesn't exist.  When it breaks the remote
usage I know exactly why and I know that I need to manage things
differently, taking into account the local environment and the
environment provided by the TRAMP connection.  I would not assume that
all code referencing find-program needs to start overriding its value if
default-directory is classed as being remote.

(I appreciate that "-program" may signal that this value is intended to
be the executable name rather than a complete path, but the semantics of
the problem are the same.)

That said, I do not claim to be TRAMP expert, I just use it.  A TRAMP
maintainer is probably better positioned to clarify the preferable way
to configure paths to executables so they work locally and remotely.

-- 
Morgan Willcock