GNU bug report logs - #76955
30.1; php-ts-mode-php-executable default path may not match remote path

Previous Next

Full log

View this message in rfc822 format

From: Morgan Willcock <morgan <at> ice9.digital>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: v.pupillo <at> gmail.com, 76955 <at> debbugs.gnu.org
Subject: bug#76955: 30.1; php-ts-mode-php-executable default path may not match remote path
Date: Sat, 15 Mar 2025 15:03:57 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Morgan Willcock <morgan <at> ice9.digital>
>> Cc: v.pupillo <at> gmail.com,  76955 <at> debbugs.gnu.org
>> Date: Sat, 15 Mar 2025 13:07:54 +0000
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Morgan Willcock <morgan <at> ice9.digital>
>> >> Cc: Vincenzo Pupillo <v.pupillo <at> gmail.com>,  76955 <at> debbugs.gnu.org
>> >> Date: Sat, 15 Mar 2025 11:03:40 +0000
>> >>
>> >> Eli Zaretskii <eliz <at> gnu.org> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.