[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1052460: marked as done (tech-ctte: In re ticket 1051368: including Selenium Manager in python3-selenium package)

Your message dated Sun, 24 Sep 2023 11:05:40 +0100
with message-id <875y3zlwcr.fsf@melete.silentflame.com>
and subject line Re: Bug#1052460: tech-ctte: In re ticket 1051368: including Selenium Manager in python3-selenium package
has caused the Debian Bug report #1052460,
regarding tech-ctte: In re ticket 1051368: including Selenium Manager in python3-selenium package
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1052460: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052460
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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.

--- End Message ---
--- Begin Message --- 
Hello,

On Fri 22 Sep 2023 at 05:00pm +02, Helmut Grohne wrote:

> 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

I'm going ahead and closing the bug as not only non-actionable but
prematurely brought to the TC, but discussion can continue here.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: