Bug#1052460: tech-ctte: In re ticket 1051368: including Selenium Manager in python3-selenium package
Hello Jonathan,
On Fri, Sep 22, 2023 at 09:50:51AM -0400, Jonathan Kamens wrote:
> 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.
Let me observe that in quite some cases, Debian packages do not include
the full functionality that upstream provides. This can have various
reasons such as licensing, porting and other trade-offs. Such reduction
of functionality usually is left at the discretion of the maintainer.
> 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."
Thank you for providing the background.
> 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.
In essence, this is an upstream decision. Debian may have a different
idea on this. Usually, deviating from upstream is not welcome, so there
should be good reasons for doing so.
> 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.
Reading up the bug log indicates to me that Carsten refuses to do the
work to package the Selenium Manager. This is his constitutional right.
He suggested filing an RFP bug, which indicates that he is not opposed
to including the Selenium Manager in Debian and merely is opposed to
doing the necessary work.
> 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
This second step seems incompatible with established Debian processes
such as DFSG item 2.
> 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 seems quite evident that the primary disagreement here is about what
it takes to package Selenium Manager rather than whether it should be
included. This is also evident from your previous bug not having been
closed by Carsten.
> It does not seem like this is too much work for Debian's
> python3-selenium package build scripts to do.
I think this and the question of who will be doing the work is the core
disagreement here.
In effect, you are asking the CTTE to overrule a maintainer. If
successful, that could authorize you to change the selenium package in
the way you would like to see.
Such a decision does not usually come about on vague terms. Quite to the
contrary, the CTTE is supposed to choose among available solutions. One
obviously available solution is the status quo that you dislike. The
other solution that you project is not available in the sense that you
have only given a rough sketch rather than say a patch. In effect, your
solution is not available and the CTTE cannot rule on this matter in
your favour.
Like Carsten, I also think that adding Selenium Manager to Debian is not
trivially implemented. In particular, the procedure you have given is
one that is not acceptable by the Debian project as it fails e.g. DFSG
item 2.
I recommend that you work on actually packaging Selenium Manager.
Carsten suggested doing it as a separate binary package. His suggestion
makes sense to me, because Selenium Manager is supposed to be used by
multiple bindings and Debian also includes Perl and Ruby bindings that
would be similarly affected and should not depend on Python. I expect
that Carsten would be willing integrate a separately packaged Selenium
Manager into python3-selenium.
I also note that your insistence on the severity of the bug is not
useful. While I agree that the status quo is a significant regression in
ease of use, having an RC bug against python3-selenium would have the
effect of removing it from trixie. If we have a choice of having an
inconvenient python3-selenium or no python3-selenium in trixie, I prefer
the former.
Do you have any objections to closing this bug? In its current form,
this request is not actionable to the CTTE.
Helmut for the CTTE
Reply to: