Inherit/use PATH variable from the client

[IndianBoy42]

I use mason.nvim to install most of my lsps in neovim. Which installs everything to ~/.local/share/nvim/mason/bin to not interfere with the system. I think adding an argument to the client binary to take a custom PATH variable (or just some directories to prepend to the PATH) would work to use these.

The alternatives are:

• Compute the absolute path of the binary from the editor and pass that to --ra-mux-server (nothing in ra-multiplex side)
• Make mason install to a location that I add to my global path (or at least to the PATH that ra-multiplex-server sees)
• have ra-multiplex binary automatically get the PATH env variable and send it to the server (rather than having to manually add it on the editor)

I think if two ra-multiplex clients specify the same server but with different PATHs they should be run with different instances. Does that make sense? I'm just considering if the different PATHs might be used to require different versions of the server. Actually what makes more sense is to use the actual absolute path of the found server binary.

I can help with the implementation if you're happy with the feature and the direction for it.

[pr2502]

Hi, I'm not sure I entirely understand what the issue is (I've never used mason.nvim), wouldn't it be solved by setting the path for the ra-multiplex-server in the service file (or whichever way you launch it)?

Any passing of variables between the ra-multiplex client and server is complexity that makes debugging harder so unless it's a very common use case or it cannot be easily solved another way I'd prefer not to add it to ra-multiplex.

[IndianBoy42]

Mason.nvim does not install the lsps that we might want to use with ra-multiplex globally, it just changes the PATH variable inside neovim so that any plugin or tool that needs it can find it automatically. except ra-multiplex-server doesn't live inside neovim so its PATH is unchanged. Where the lsp/tool is installed and the change in environment is technically a hidden implementation detail of Mason.nvim, adding it to the ra-multiplex service doesn't seem appropriate.

There are other reasons that neovim may have a different PATH environment or find a different executable for the same command as ra-multiplex-server: python/conda virtual environments, node/julia/go version managers that also work in userspace, nix flakes/dev environments etc. where the just add it to the global service PATH solution is even less viable if not impossible.

I think the least surprising thing for the user, and to be a true drop-in replacement, ra-multiplex --server <name> and <name> run by the client editor should trigger the same program.

Resolving the command to the full absolute path on the client side and sending that is probably the least complex implementation now that I think about it more, but I still think it should be done in ra-multiplex not in the editor.