Thank you to everyone here who explained the context of which I was
unaware surrounding this issue. I appreciate that you took the time to
do that. A couple points in response...
* For the record, if the package maintainer had said in the other
ticket, "Yes, the package is broken, but including Selenium Manager in
the package is not currently possible because the tools to build it in
Debian don't exist and that's not a trivial problem to solve," then we
would be having a very different conversation right now, and I would
never have escalated this to the technical committee. Instead, what they
said was (paraphrasing), "I don't think we should consider the package
broken just because it used to work and now suddenly stopped working and
the same code that used to work now causes a stack trace, because if the
user reads the stack trace and spends about 30 minutes Googling they
should be able to figure out how to work around the problem." This is
not, in my opinion, a reasonable response. Just because fixing the issue
"correctly" involves a lot of work we can't currently do doesn't make
that a reasonable response. I realize that adjudicating whether a
response from a maintainer is reasonable is outside the purview of the
technical committee and I'm not asking for a "ruling" on this one way or
another; I just feel compelled to point out that the only reason why I
escalated to the technical committee was because the maintainer was not
forthcoming.
* I want to push back a bit on the attitude I seem to be hearing here,
that people shouldn't report issues unless they're prepared to do the
work to fix them, or the corollary, that if no one is currently prepared
to do the work to fix an issue then it should just be closed. I don't
think people should be rebuffed from reporting real issues just because
they don't have the skills or time necessary to fix them themselves, and
I think that unresolved or incompletely resolved issues should be kept
open until they can be resolved properly.
* Speaking as an end user, I do not agree with the statement, "I see
that python3-selenium now has a NEWS.Debian entry that points to
README.Debian, which seems like a reasonable way to bring this to users'
attention." Most users don't know to look for either of these files.
It's simply not going to occur to them that this is a Debian issue
requiring special handling; they're simply going to think the package is
broken. I could be wrong about this, of course, but this is my gut
instinct. Given that the Python code is always going to crash in the
same place if it can't find Selenium Manager, then a workaround for this
problem would be patch the code so that it catches the exception and
points the user at README.Debian before re-raising it.
* If this really is going to be "fixed" just with documentation, then I
would argue that the better documentation fix would be to tell the user
how they can install Selenium Manager themselves rather than telling
them how to hack their code to work around the missing Selenium Manager.
That would mean telling amd64 users where to download it, and providing
instructions for users on other architectures on how to compile and
install it. Heck, maybe even put a shell script in the python3-selenium
package that compiles and installs it and just tell the user what it
does (full disclosure is important here!) and how to run it.
If there is interest in a combination of the above two changes as an
acceptable improved fix for this issue, and someone can point me at
where I can get started learning how to submit patches to Debian
packages, then I am willing to work on this and submit a patch.
* I agree that patching the Python binding on Debian to restore the
previous behavior would be a better short-term fix than what we have now
(though I think a combination of the two fixes above would be
preferable). However, I'm not sure that's a viable long-term fix,
because I imagine that if Selenium Manager "catches on" it will become
harder and harder to patch it over time. There's no saying whether I'm
right about that or if I am what the time-frame will be, and it could
actually go in the opposite direction, i.e., if the maintainers of
Selenium get enough push-back about their choice to require their
Selenium Manager binary they may reverse that decision.
* Another potential fix for this is to package Webdriver Manager
<https://pypi.org/project/webdriver-manager/>, which is essentially a
pure-Python replacement for Selenium Manager, make it a dependency of
python3-selenium, and patch python3-selenium to use it by default
instead of Selenium Manager. I think this would satisfy everyone's
concerns, and it would restore python3-selenium to a working state
out-of-the-box.
I am also willing to work on this and submit a patch if there is
interest in this solution.
* In my opinion, keeping the old version of the Python bindings that
didn't require Selenium Manager would have been a better fix than
upgrading to a version that doesn't work and requires the user to make
platform-specific changes to their code to make it work. Granted, this
too is only a short-term fix, so it would only be a stopgap measure
until such time as Debian figures out how to build and package Selenium
Manager. So this isn't a workable solution if that's unlikely to happen
any time soon. If there *is* progress being made on that, and none of
the other possible solutions I've enumerated above are considered
workable for whatever reason, then I think this one should be considered.
Thanks,
Jonathan Kamens
