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

Support downloading exe when running WSL #170

Closed
G-Rath opened this issue May 21, 2020 · 3 comments · Fixed by #172
Closed

Support downloading exe when running WSL #170

G-Rath opened this issue May 21, 2020 · 3 comments · Fixed by #172

Comments

@G-Rath
Copy link
Contributor

G-Rath commented May 21, 2020

Summary

I use WSL for development, which works really well for most things, but one of the last hurdles I've been trying see if I can nicely resolve is around feature testing with Chrome via Selenium.

Currently this can be accomplished by using chromedriver.exe, and having Selenium use that instead of letting it try and start chromedriver itself (aka "don't run webdriver, we'll run webdriver")

The problem is that when using webdrivers, it sees itself as being on Linux (understandably because it mostly is), and attempts to do all the Linux things, such as looking for Chrome in the Linux places, and downloading the Linux version of the webdriver.

Initially what happens is that webdrivers attempts to find chrome, and fails, throwing an error (understandably) - to work around this, I can set WD_CHROME_PATH to point to a bash script (aka fake-chrome.sh).

This makes webdrivers happy, and I just have to run chromedriver.exe myself in a terminal, and set the url: property.

However, it's actually possible to improve this further so that webdrivers does its thing on WSL as it does for native Windows, Linux, and MacOS - that is, it downloading the right version of the webdriver based on the chrome version.

Since WSL supports running exes, and chromedriver.exe supports flags in both Windows & Linux format (so both chromedriver.exe --version & chromedriver.exe /version works), you can actually replace the Linux chromedriver downloaded by webdrivers with the Windows version, and things will "just work".

This leads into the actual feature request of this issue: webdrivers on WSL will download the Linux version currently.

If webdrivers supported downloading the Windows version of chromedriver, named as just chromedriver (so that the rest of the code didn't need to change), then WSL support would be nearly on par with the rest.

You can check if you're running on WSL a few different ways, but there doesn't seem to be a gem version of is-wsl - I'm personally happy for this to be walled off behind an explicit env value, since you'll still need to point to a fake-chrome script file.

The contents of that file at this point would contain the following:

#!/usr/bin/env bash

echo $(powershell.exe '(Get-ItemProperty "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion')

My apologies for this rather lengthy issue, but I wanted to lay out the whole story.

I'm happy to do the actual implementation work, but wanted to check if this is something webdrivers would be happy to have in the first place :)

Ultimately the first iteration of an implementation I'd gun for is "if WD_IN_WSL: download driver exe and rename, then carry on as if linux".

@kapoorlakshya
Copy link
Collaborator

@G-Rath WSL support would be great! Please go ahead and submit a PR, and I'd be happy to review it.

@kapoorlakshya
Copy link
Collaborator

Ultimately the first iteration of an implementation I'd gun for is "if WD_IN_WSL: download driver exe and rename, then carry on as if linux".

I would prefer the detection to be automated instead of relying on the user to provide an ENV flag. How about checking /proc/version as described in this post? https://stackoverflow.com/questions/38859145/detect-ubuntu-on-windows-vs-native-ubuntu-from-bash-script

@G-Rath
Copy link
Contributor Author

G-Rath commented May 22, 2020

I would prefer the detection to be automated

Awesome, so would I - that /proc/version is how it's done in is-wsl, and would be the way I'd go.

I initially suggested the env value just to keep complexity down since adding automatic detection can easily be added afterwards, but if you're keen for it all at once, I'm game :)

(The only concern I'd have is if WSL got the ability to use the linux webdriver, but it'll be equally easy to add env support if that come ever comes).

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 a pull request may close this issue.

2 participants