Although tempting, we really can't install WebKitWebDriver into bindir because it's not a versioned directory: it won't be parallel-installable with future WebKit APIs. It belongs in pkglibexecdir, where we already install jsc and MiniBrowser.
Tom, if you don't update your RPM files list, this will be a sad way for your next rebuild to fail. ;)
Created attachment 319688 [details] Patch
(Do we need to update file paths anywhere specific to WebDriver?)
Comment on attachment 319688 [details] Patch This is on purpose, web driver processes are expected to be in $PATH, other browsers also install the web driver process in /usr/bin, it makes easier for selenium drivers to find the process.
(In reply to Michael Catanzaro from comment #0) > Although tempting, we really can't install WebKitWebDriver into bindir > because it's not a versioned directory: it won't be parallel-installable > with future WebKit APIs. It belongs in pkglibexecdir, where we already > install jsc and MiniBrowser. WebKitWebDriver doesn't expose any public API, it currently links to libjavascriptcore, but only because JSON implementation is in JSC, once it's moved to WTF, we will only link (statically) to WTF.
(In reply to Carlos Garcia Campos from comment #5) > WebKitWebDriver doesn't expose any public API, it currently links to > libjavascriptcore, but only because JSON implementation is in JSC, once it's > moved to WTF, we will only link (statically) to WTF. That doesn't change the fact that it is not parallel-installable. Unfortunately if you want it in bindir, I think the only option is to add our API version to the name of the binary. We don't want to wind up in a situation in three years where WebKitWebDriver is the old version you don't want and only the new version has some ugly version number in the filename. Best do it now. Alternative: we could move our subprocesses into a subdirectory of pkglibexecdir and ship an /etc/profile.d script to add it to PATH automatically. Then after we release a new API version, we change the script to point to the new API's pkglibexecdir instead. Not sure if this would be nicer or if it's just dumb.
Here's a better idea. Let's install it into libexecdir, and also install an unversioned symlink into bindir. In the future, we can adjust the symlink to point to the latest API version when desired. Then you can use WebKitWebDriver from PATH if you don't mind not knowing which version you'll get, and all versions will still be parallel-installable. Does that make sense? I think we should do that for MiniBrowser and jsc too. At least jsc would be nice to have in PATH.
My point is that the web driver should still be backwards compatible even if we bump the API (once we stop linking to jsc, of course). Unless the json-rpc protocol changes or the DBUs API. But, yes, maybe it's probably safer to install it versioned and then use symlinks. My main concern with libexecdir is that every distro does its own thing, so there's no sane default to use in the selenium driver. A good default value makes: from selenium import webdriver epiphany = webdriver.Epiphany() just work. Otherwise the user needs to know where the driver process is installed and do something like: from selenium import webdriver epiphany = webdriver.Epiphany(executable_path="/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebDriver") And that test/script will not work in any distro/platform. Selenium drivers normally use the process name, and assumes it's in PATH when the default is used, or even the full path /usr/bin/foodriver as the default: https://github.com/SeleniumHQ/selenium/blob/master/py/selenium/webdriver/chrome/webdriver.py#L32 https://github.com/SeleniumHQ/selenium/blob/master/py/selenium/webdriver/firefox/webdriver.py#L55 https://github.com/SeleniumHQ/selenium/blob/master/py/selenium/webdriver/safari/webdriver.py#L34 https://github.com/SeleniumHQ/selenium/blob/master/py/selenium/webdriver/edge/webdriver.py#L27 https://github.com/SeleniumHQ/selenium/blob/master/py/selenium/webdriver/opera/webdriver.py#L44
(In reply to Michael Catanzaro from comment #6) > That doesn't change the fact that it is not parallel-installable. I wonder, how important is this in practice? Speaking with my Debian maintainer's hat on, we already have libjavascriptcoregtk-3.0-bin and libjavascriptcoregtk-4.0-bin, both providing /usr/bin/jsc and conflicting with each other. > Let's install it into libexecdir, and also install an unversioned > symlink into bindir. That would be similar to what Debian does with alternatives. Something like that is also doable, but again I wonder if this is something that users will really need in practice.
(In reply to Alberto Garcia from comment #9) > Speaking with my Debian maintainer's hat on, we already have > libjavascriptcoregtk-3.0-bin and libjavascriptcoregtk-4.0-bin, both > providing /usr/bin/jsc and conflicting with each other. I guess you also have a patch to change the install location of jsc. We install it only to libexecdir to ensure it is parallel-installable.
(In reply to Michael Catanzaro from comment #10) > (In reply to Alberto Garcia from comment #9) > > Speaking with my Debian maintainer's hat on, we already have > > libjavascriptcoregtk-3.0-bin and libjavascriptcoregtk-4.0-bin, > > both providing /usr/bin/jsc and conflicting with each other. > > I guess you also have a patch to change the install location of > jsc. We install it only to libexecdir to ensure it is > parallel-installable. Not really a patch, but yeah, I move it from libexecdir to bindir during the package creation. The question is: would that work with WebKitWebDriver ?
Carlos, I think we should at least append the API version to keep it parallel-installable. Right now this will be the only file conflict we'll have when introducing a GTK+ 4 API and we'll have to figure out a new name for it then. E.g. we could name it: WebKitWebDriver-4.0.