-
Notifications
You must be signed in to change notification settings - Fork 56
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
Skip invalid executables #585
base: main
Are you sure you want to change the base?
Conversation
Thanks for working on this. @dhruvmanila this overall seems reasonable to me. What do you think? |
src/common/server.ts
Outdated
message += `(Reqiuired at least ${versionToString( | ||
MINIMUM_SUPPORTED_EXECUTABLE_VERSION, | ||
)}, but found ${versionToString(ruffVersion)} instead)`; | ||
traceError(message); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should also display this message to the users using vscode.window.showErrorMessage
. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
during findRuffBinaryPath
it may skip several binaries, I think it'd be annoying to send all of them as user facing warnings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This message shouldn't be required because we already check that later on. Refer to my other comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤷♂️
src/common/server.ts
Outdated
} catch (ex) { | ||
traceInfo(`Skip invalid executable from ${strategy}: ${executable}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we include the exception message as well? Are we able to capture the one in #426 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, makes sense. Since ex
maybe multi line error, what is correct format to put it in there? I don't think put it in parantheses be a good style.
traceInfo(`Skip invalid executable from ${strategy}: ${executable}:\n${ex}`);
is this correct to you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be fine but I'd need to play around with it to check how it renders in the output window. I can do that when I'm testing before merging the PR.
I can test it out before merging. |
Co-authored-by: Dhruv Manilawala <[email protected]>
Thank you! |
@T-256 feel free to ping me once you've made all the changes from your side. I can then own it to test and merge the PR. |
I'm done. Ping me to review when you applied your changes, Thank you. |
(It's a bit late here, so will look at it tomorrow.) |
Unfortunately, I'm still getting the errors from Complete logs
|
We use
|
I'm not sure I follow what you're saying here. Overall, I'm a bit hesitant to merge this because it doesn't really solve the pyenv shims issue. I might need to spend some time playing around with a couple of solutions to understand what we can do about it. |
I looked into this a bit more and am unable to figure out the root cause of why it's failing to start the server. Are you planning to look into the failure? |
by looking through this part of your logs:
Can you test with 3e43982? |
If you want a way to reproduce this, then I did the following:
|
@dhruvmanila I understand your issue at here, you want to support pyenv, but it's out scope of this PR.
Since we are not yet support pyenv, I think it makes sense to skip them for now. |
Yeah, that's fine, thanks. If that's not the case, then can you clarify what this PR is trying to solve? Can you provide a test scenario where this PR helps in comparison to what's on |
## Summary I noticed this in #585 that we would not be able to look at the error message when the server crashes because the output window got disposed. This is because the disposable is tied up with stopping the server. This PR updates that to include the disposable to the extension context so that it gets disposed only when the extension is deactivated. ## Test Plan Run the scenario from #585 to make sure that the "Ruff Language Server" window is not disposed in case the server crashed.
it solves below scenarios when native server has been chosen: on on |
Thanks for providing them but now I'm even more confused, please bear with me 😅
My main confusion is that you mentioned not to support pyenv here:
So, this is not really true as is evident by my testing using #585 (comment). Do you have a scenario or a recording which showcases that it's working as you've intended? Do you mind sharing that? |
Summary
This PR introduces skip by default on executables that is unable to parse version from
<binary> version
.Also, defined minimum-supported-ruff-version that causes to skip outdated versions if hit them in executable discovery.
Done partially #426 and #323 in conditions of native server chosen.
Test Plan
didn't run any tests. I think it should work.