Package: tech-ctte Severity: important This referral to the technical committee concerns the issue identified in ticket 1051368. I appear to be at an impassse in that ticket with the maintainer of the python3-selenium package referenced in that ticket, and they have stopped responding to my comments in the ticket.
Executive summary The current python3-selenium package does not include all of the components that the vendor expects to be included in the package, and as a result it does not work. This is a regression from previous versions of the package, i.e., it was working just fine and then stopped working at all in the new release. The workaround suggested by the maintainer of the package is inconsistent with the vendor's expectations and in my opinion inadequate. There is a straightforward fix which the package maintainer has declined, without explanation, to implement. Additional details The current version of the Selenium bindings for all supported programming languages relies on a Rust executable called Selenium Manager for managing the webdriver executables required for the various browsers that the bindings interact with. This Rust program is intended to be packaged and shipped with the Selenium bindings, as indicated by the facts that (a) it is included in the official PyPI packages for the Python bindings and (b) the maintainers of Selenium state this explicitly. Quoting from https://www.selenium.dev/documentation/selenium_manager/ : "Selenium bindings use this tool by default, so you do not need to download it or add anything to your code or do anything else to use it. ... Selenium Manager is the official driver manager of the Selenium project, and it is shipped out of the box with every Selenium release." While I don't much care for the fact that the maintainers of Selenium have opted to make all of the language bindings depend on a compiled executable written in a different language, this is the technical decision that they've made, and it's their prerogative. When Selenium Manager is not included with the language binding, it fails to find the webdriver executables it needs and stops working unless the developer modifies their code to explicitly say where the executable is located, the workaround suggested by the python3-selenium package maintainer in README.Debian. This makes the affected Selenium code non-portable, when the whole point of Selenium Manager is to increase code portability rather than decreasing it. In addition, the only way the developer has to know they need to do this on Debian is to find and read the README.Debian file, which (a) most developers aren't going to think to do and (b) due to a packaging error wasn't even included in the python3-selenium package. As I noted in ticket 1051368, building Selenium Manager so that it can be included in the package is straightforward. In particular, it requires just four steps: 1. Download the Selenium source code from GitHub or somewhere else it is published 2. Download a bazel binary from https://github.com/bazelbuild/bazelisk/releases and make it executable in your search path 3. Unpack the Selenium source code 4. Run "bazel build //rust:selenium-manager" in the top directory of the Selenium source code After these four steps, the Selenium Manager is available for packaging in bazel-bin/rust/selenium-manager. It does not seem like this is too much work for Debian's python3-selenium package build scripts to do. To summarize, including Selenium Manager in the package (a) is straightforward, (b) is what the upstream vendor intends, (c) would make the package work like it's supposed to when it doesn't currently, and (d) would eliminate the necessity for developers to use a platform-specific hack to make their Python Selenium code work on Debian.