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

fall back to system ruff executable without executable setting #97

Merged
merged 3 commits into from
Sep 12, 2024

Conversation

TheJJ
Copy link
Contributor

@TheJJ TheJJ commented Sep 3, 2024

otherwise I have to either configure the path in the project's pyproject.toml or unnecessarily in the lsp configuration :)

@jhossbach
Copy link
Member

Hi, sorry for the delay. I am not sure what the use case for this is though - if the executable is not set the ruff should automatically find the "correct" executable by using python -m ruff, see here:

if p is None:
log.debug(
f"Calling ruff via '{sys.executable} -m ruff'"
f" with args: {arguments} on '{document_path}'"
)
cmd = [sys.executable, "-m", "ruff", str(subcommand)]
cmd.extend(arguments)
p = Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE)

Does this not work for you?

@TheJJ
Copy link
Contributor Author

TheJJ commented Sep 12, 2024

Hi! - no worries :)
Yes, python3 -m ruff does not work for me, since the Gentoo dev-util/ruff package doesn't install the Python module
Apart from shell completions and documentation, I only have /usr/bin/ruff.

I think it's alright to use shutil.which to search in the PATH for the executable, since I don't see a useful way to hard-code the executable path in the in-project pyproject.toml, and hard-coding it in the lsp configuration doesn't seem right when it's just available in the PATH.

What do you think?

@jhossbach
Copy link
Member

Ah, I wasn't aware of this issue.
I would suggest including os.shutil in case python -m ruff fails, since I don't know if removing that could potentially affect others.
I'll add something to the PR.

@TheJJ
Copy link
Contributor Author

TheJJ commented Sep 12, 2024

you could have a look once if ruff has an entry point in from importlib.metadata import entry_points, so we don't have to check it again and again and execute a new python subprocess?

@jhossbach
Copy link
Member

Instead of using importlib, I moved finding the correct executable to a new function which is now cached, so it should only run once with the given executable.
Can you try to see if that works?

@jhossbach
Copy link
Member

Hmm, I seemed to have missed those issues before pushing, let me look into it.

@jhossbach
Copy link
Member

This should work now, please check if it does.

Copy link
Contributor Author

@TheJJ TheJJ left a comment

Choose a reason for hiding this comment

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

from what I understand now, what you whish is:

  • if executable is set and exists, use it
  • otherwise, try the ruff module
  • otherwise, use the system executable

I'd propose to implement is this way:

  • if executable is set, use it, and crash if it doesn't exist. silent swiches of the used program are unexpected and hard to debug.
  • otherwise, check once if the ruff module exists and use it
  • otherwise, use the system executable found by which.

maybe some way to prefer the executable would be better, because then we could bypass invoking a new python interpreter for every ruff invocation eats a bit of latency. or calling the python module in the same interpreter.

pylsp_ruff/plugin.py Outdated Show resolved Hide resolved
pylsp_ruff/plugin.py Outdated Show resolved Hide resolved
@TheJJ TheJJ force-pushed the use-system-ruff branch 3 times, most recently from 4bf5086 to c235923 Compare September 12, 2024 15:47
@TheJJ
Copy link
Contributor Author

TheJJ commented Sep 12, 2024

I've implemented an improved version, which uses the configuration value without fallback, or it tries the python module and then system executable next.

one could optimize this to eliminate the extra python interpreter invocation if using the module (for latency improvement) by re-using the current interpreter instead.

@TheJJ TheJJ force-pushed the use-system-ruff branch 5 times, most recently from 67c77da to 12925c5 Compare September 12, 2024 16:02
@jhossbach
Copy link
Member

Looks really nice, but I am not sure the ImportError is propagated the way you probably want it to, e.g. when testing with neovim the error does not reach the editor.
I think there is a workspace.show_message method which could work here (although I haven't tested it).

@TheJJ
Copy link
Contributor Author

TheJJ commented Sep 12, 2024

which import error, if no executable/module is found?

if there's a better way than crashing with an exception, we should surely use it :)

@jhossbach
Copy link
Member

jhossbach commented Sep 12, 2024

Similarly to log.error(...), the RunTimeError will only be seen in pylsps log file.
I just tried to try except the Error for a dummy executable and report it to the editor with workspace.show_message(...) but so far this did not work for me.
Unfortunately I don't have the time to look into it until next week.

@TheJJ
Copy link
Contributor Author

TheJJ commented Sep 12, 2024

maybe we could merge this for now since it's not making it worse than before when no ruff was found :)
then come up with sane error propagation to notify the user properly.

@jhossbach
Copy link
Member

I took the liberty of removing the RuntimeErrors for now, otherwise thanks a lot for the PR!

@jhossbach jhossbach merged commit 041c695 into python-lsp:main Sep 12, 2024
5 checks passed
@TheJJ
Copy link
Contributor Author

TheJJ commented Sep 13, 2024

great :)
thanks for the tool!

@TheJJ TheJJ deleted the use-system-ruff branch September 13, 2024 14:33
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.

2 participants