Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load shell environment when launching from GUI #1461

Merged
merged 2 commits into from
Oct 11, 2022
Merged

Load shell environment when launching from GUI #1461

merged 2 commits into from
Oct 11, 2022

Conversation

TitanNano
Copy link
Contributor

When lapce attempts to launch sub-processes (i.e. a LSP) that depend on environment variables like a customized PATH it will fail as long as it has been launched from the GUI (at least on macOS).

This is due to the fact that i.e. macOS does not load the user's shell environment when launching an app. This can be mitigated by starting a login shell and extracting all environment variables from it. A strategy described in this comment on the Atom Editor project.

I have tested this on macOS, and it resolved all issues of lapce not being able to find LSP executables like pylsp. For Linux, I do not know if it is actually necessary or if the correct environment is available to lapce there.

Copy link
Collaborator

@panekj panekj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm against this type of workaround

@TitanNano
Copy link
Contributor Author

@panekj
a. What do you not like about it?
b. what would you suggest as an alternative solution?

@panekj
Copy link
Collaborator

panekj commented Oct 9, 2022

a) the fact that it's messing with environment
b) not doing it at all, plugins should correct their behaviour

@TitanNano
Copy link
Contributor Author

TitanNano commented Oct 9, 2022

a) the fact that it's messing with environment

Fair point. What about setting env variables on the Command when launching the subprocess?

b) not doing it at all, plugins should correct their behaviour

I don't see how plugins can resolve this issue. Even when a plugin accepts a serverPath to, i.e. /opt/homebrew/bin/pylsp the LSP will then not be able to locate the python interpreter, as it has also been installed via Homebrew and is not in the macOS standard PATH.

Lapce not having access to Homebrew installed executables is a high inconvenience for users on macOS.

@codecov-commenter
Copy link

codecov-commenter commented Oct 9, 2022

Codecov Report

Merging #1461 (155df0e) into master (7c993f9) will decrease coverage by 0.00%.
The diff coverage is 0.00%.

@@            Coverage Diff            @@
##           master   #1461      +/-   ##
=========================================
- Coverage    6.10%   6.09%   -0.01%     
=========================================
  Files         123     123              
  Lines       49822   49853      +31     
=========================================
  Hits         3041    3041              
- Misses      46781   46812      +31     
Impacted Files Coverage Δ
lapce-ui/src/app.rs 0.00% <0.00%> (ø)
lapce-data/src/data.rs 0.00% <0.00%> (ø)
lapce-ui/src/editor/tab_header_content.rs 0.00% <0.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants