-
Notifications
You must be signed in to change notification settings - Fork 293
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
VS Code Extension Doesn't Recognize Sapling Repo #282
Comments
Thanks for reporting this! If you go to the "output" channel at the bottom, then switch to "Sapling ISL", you'll be able to see the logs from ISL, which should show an error message about why it failed to find a repository. There's a similar code path here for detecting if the sapling command is not installed correctly. I'm wondering if this is related to "sl" conflicting with Set-Location on powershell. We don't currently have a VS Code config for the extension to set which sl executable name to use, but if this is related to the powershell issue I think that would be a good first step for us to add. |
Summary: When spawning ISL from the CLI, we allow `--command` / infer the command executable from the `sl` in `sl web`. In vscode, we don't have the same direct place to infer the command from. `sl` is a good guess, and works if you've installed `sl` on your path. But we should allow a config to control exactly what installation / path we spawn ISL from. This may help with #282 Reviewed By: bolinfest Differential Revision: D41590875 fbshipit-source-id: 8b909e527e5f0152396ef9263edbeff3eca11f9b
Hmm you're right. Looks like it's not finding that command. I did rename alias in powershell though
|
dce1ec6 updates our logic to try |
I'll also add a change so that we detect this as sl not being found on the PATH rather than as an invalid repo. Looks like our ENOENT check doesn't work on windows. |
Summary: I thought we could depend on execa to manage returning `ENOENT` for invalid command names, but apprently this doesn't always happen on windows. By making this test work on windows, we show a more accurate "sl is not installed correctly" rather than "this is an invalid repository". See this discussion for more information: sindresorhus/execa#469 (comment) Example of a user on windows not triggering ENOENT: #282 (comment) Instead, we should detect invalid commands on windows with exit code 1 (but only on windows). The use of this detection is isolated to findRoot, which is where we determine if the command being used is valid. If some other issue triggered this code path, showing "this is not a valid sl command" is also a reasonable error message. Plus we still log the error for debugging purposes. This may also help with #282. Reviewed By: bolinfest Differential Revision: D41595211 fbshipit-source-id: 7cff8eafd58f6da14bb85f4289eb25ddbcf5273c
A new version (0.1.5) of the vscode extension has been published with these fixes. Let us know if this helps, or if you still see problems with this! |
It works! The only issue was that the open link for the installation docs didn't work in the error screen (maybe a VS Code issue) and I had to add the sapling directory to my environment variables in windows. |
which error screen?
You mean you had to add the folder with |
Ah, so I believe the logic for the button is here: sapling/addons/isl/src/App.tsx Lines 129 to 137 in 5985299
The client portion of sapling/addons/vscode/webview/vscodeWebviewPlatform.ts Lines 28 to 30 in 5985299
which should be handled here: sapling/addons/vscode/extension/vscodePlatform.ts Lines 37 to 40 in 5985299
so not sure where things are going wrong. |
…en starting. (#307) Summary: This was reported as part of #282. Specifically, if `sl` (or `sl.exe`) is not found on the `$PATH`, ISL shows an error box with a **See installation docs** button, and clicking it sends a `platform/openExternal` message to the server to open an external URL. This message was not getting processed because the handler was only processing messages when the `currentState` of `ServerToClientAPI` was `"repo"` (i.e., not `loading` or `error`). Failing to find `sl` put things in the `error` state, so the `platform/openExternal` message was ignored. Note that the bulk of the messages are processed by `handleIncomingMessageWithRepo()`, which reads the `Repository` off `this.currentState`, though that is not present when in the `loading` or `error` state. As such, this diff adds a conservative fix, which is to handle only messages of type `PlatformSpecificClientToServerMessages`, as `platform.handleMessageFromClient()` can be called without a `Repository` object. Pull Request resolved: #307 Test Plan: Verified clicking the **See installation docs** button works now. Reviewed By: ndmitchell Differential Revision: D41845324 Pulled By: bolinfest fbshipit-source-id: 4d90f4dda022c82951f71f22206d424afcfbd4c4
When I open up the ISL using VS Code, it gives me on the main screen.
I'm using the latest version
Sapling 0.1.20221118-210929-cfbb68aa
on windows using Powershell. I can get sl to work in the web browser and on the console as well.Any recommendations?
The text was updated successfully, but these errors were encountered: