Bug 176267 – [GTK] WebKitWebDriver should be installed into libexecdir

• Component: WebDriver
• Status: RESOLVED WONTFIX

[Michael Catanzaro]

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.

[Michael Catanzaro]

Tom, if you don't update your RPM files list, this will be a sad way for your next rebuild to fail. ;)

[Michael Catanzaro]

Created attachment 319688 [details]
Patch

[Michael Catanzaro]

(Do we need to update file paths anywhere specific to WebDriver?)

[Carlos Garcia Campos]

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.

[Carlos Garcia Campos]

(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.

[Michael Catanzaro]

(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.

[Michael Catanzaro]

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.

[Carlos Garcia Campos]

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

[Alberto Garcia]

(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.

[Michael Catanzaro]

(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.

[Alberto Garcia]

(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 ?

[Michael Catanzaro]

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.