[py] Fix selenium-manager binary location

[jameshilliard]

User description

This build was incorrectly migrated in #14837 as selenium-manager is expected to be in the selenium/webdriver/common/selenium-manager library path rather than a binary named selenium.webdriver.common.selenium-manager installed in the script path.

🔗 Related Issues

Fixes #14837.

💥 What does this PR do?

Fixes sdist selenium-manager binary name/path.

🔄 Types of changes

• Bug fix

---

PR Type

Bug fix

---

Description

• Fix selenium-manager binary location in Python package

• Change from bins to ext-modules configuration

• Correct path for selenium-manager in library structure

---

Diagram Walkthrough

flowchart LR A["setuptools-rust.bins"] -- "change to" --> B["setuptools-rust.ext-modules"] B -- "add binding" --> C["Exec binding"] C -- "correct path" --> D["selenium.webdriver.common.selenium-manager"] 

Loading

File Walkthrough

	Relevant files
Bug fix	pyproject.toml Fix selenium-manager build configuration                                  py/pyproject.toml Changed [[tool.setuptools-rust.bins]] to [[tool.setuptools-rust.ext-modules]] Added binding = "Exec" configuration Fixed selenium-manager target path configuration +2/-1

---

[qodo-merge-pro]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis ❌ 5678 - Not compliant Non-compliant requirements: • Fix ChromeDriver connection failure error that occurs after first instance • Resolve "Error: ConnectFailure (Connection refused)" issue • Ensure multiple ChromeDriver instances can be created without errors Requires further human verification: • All requirements need verification as this PR addresses selenium-manager binary location, not ChromeDriver connection issues 1234 - Not compliant Non-compliant requirements: • Fix JavaScript execution in link href on click() for Firefox • Ensure click() triggers JavaScript in href attribute • Restore functionality that worked in version 2.47.1 but broke in 2.48.0+ Requires further human verification: • All requirements need verification as this PR addresses selenium-manager binary location, not Firefox JavaScript execution

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Configuration Change The change from bins to ext-modules with Exec binding needs verification that it correctly places the selenium-manager binary in the expected library path and maintains proper functionality [[tool.setuptools-rust.ext-modules]] target = "selenium.webdriver.common.selenium-manager" binding = "Exec"

[qodo-merge-pro]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Fix target module path format The target path appears to be incorrect for an extension module. Extension modules typically use Python module paths with dots, not file paths with hyphens. py/pyproject.toml [53-55] [[tool.setuptools-rust.ext-modules]] -target = "selenium.webdriver.common.selenium-manager" +target = "selenium.webdriver.common.selenium_manager" binding = "Exec" Apply / Chat Suggestion importance[1-10]: 9 __ Why: The suggestion correctly points out that the target for an ext-modules entry should be a valid Python module path, which cannot contain hyphens; this is a likely bug introduced by the PR.	High
Update

[jameshilliard]

The target path appears to be incorrect for an extension module. Extension
modules typically use Python module paths with dots, not file paths with
hyphens.

This suggestion is wrong, the binary does not have an underscore in its name.

[cgoldberg]

Can you explain what this fixes?

We are distributing a binary executable, not a library that can be imported by Python... so the current code using tool.setuptools-rust.bins seems correct.

[jameshilliard]

Can you explain what this fixes?

It fixes the binary executable name/path.

We are distributing a binary executable, not a library that can be imported by Python... so the current code using tool.setuptools-rust.bins seems correct.

Yes, I'm aware that we're distributing a binary executable, however the python code that wraps it expects it to be in a specific location and have a specific name. Using tool.setuptools-rust.bins is more designed for building tools called directly by users, for example it's used to build command line tools like maturin.

The tool.setuptools-rust.bins directive results in it being installed in a completely different location(the script install location) while we actually want it in the same path python library modules get installed even though it's technically still a binary executable. This is essentially the same location the prebuilt wheels put the executables.

Using tool.setuptools-rust.ext-modules tells setuptools-rust it should be installed in the python library location rather than the script path. Setting binding = "Exec" tells setuptools-rust that we want it to build a binary executable(roughly equivalent to tool.setuptools-rust.bins), this should result in the correct behavior.

[cgoldberg]

Is this change for building Selenium Manager binaries from an sdist using Python tooling?

Currently, we build a wheel using Bazel and the selenium-manager binaries are named and located exactly where the binding code expects them to be.

[jameshilliard]

Is this change for building Selenium Manager binaries from an sdist using Python tooling?

Yes, this is only for sdist builds.

Currently, we build a wheel using Bazel and the selenium-manager binaries are named and located exactly where the binding code expects them to be.

Essentially this change should make builds using the Python setuptools-rust tooling install the selenium-manager binary to the same location as Bazel does for wheels.

[cgoldberg]

Essentially this change should make builds using the Python setuptools-rust tooling install the selenium-manager binary to the same location as Bazel does for wheels.

OK.. I understand now. Thanks, this seems useful.

[cgoldberg]

I just tested this locally and was able to build/install. This is a huge improvement for doing local Python development. Previously you needed to have bazel installed, build selenium manager, copy the binary into your source tree, and adjust your Python path... or build the wheel with bazel after every change. Now you can just use standard Python tooling and do pip install -e . and you are good to go (assuming you have the rust toolchain installed).

Ininitally I was getting an error because it couldn't find Cargo.toml. So I added path like below:

[[tool.setuptools-rust.ext-modules]] target = "selenium.webdriver.common.selenium-manager" path = "../rust/Cargo.toml" binding = "Exec" 

Is there a better way to specify Cargo.toml location? Do you want to add that line to your PR?

[jameshilliard]

path = "../rust/Cargo.toml"

This path doesn't look valid for building from a sdist.

Is there a better way to specify Cargo.toml location? Do you want to add that line to your PR?

Um....I think you still have to use bazel to build the sdist(which will copy Cargo.toml to the sdist root), then you can pip install from the generated sdist.

[cgoldberg]

This path doesn't look valid for building from a sdist.

Right. I was building from local source, not an sdist, and it needed that path. Will having that path specified break building from an sdist? (I guess I can test this).

Um....I think you still have to use bazel to build the sdist(which will copy Cargo.toml to the sdist root), then you can pip install from the generated sdist.

I was able to build directly from my local source repo without using bazel at all.

[jameshilliard]

Will having that path specified break building from an sdist? (I guess I can test this).

Pretty sure it will as we can't go above the sdist root path.

I was able to build directly from my local source repo without using bazel at all.

But isn't it missing stuff like devtools which bazel needs to generate?

[cgoldberg]

But isn't it missing stuff like devtools which bazel needs to generate?

yea, that's right.. so I guess it wouldn't be viable for local development without bazel. Too bad :/

This PR is still a big improvement since it allows us to build a useable sdist with bazel. I guess the current sdist we publish to PyPI is broken?

[jameshilliard]

I guess the current sdist we publish to PyPI is broken?

Yeah, seems like it.

[jameshilliard]

yea, that's right.. so I guess it wouldn't be viable for local development without bazel. Too bad :/

Well I suppose you could just develop from the generated sdist tree and copy changes back manually.

[cgoldberg]

I just tested this locally...

I installed selenium-4.34.2.tar.gz from PyPI. The Selenium Manager binary was located at bin/selenium.webdriver.common.selenium-manager, so the bindings could not locate it.

I then built an sdist from this PR's branch (selenium-4.35.0.202507081456.tar.gz). When I install that, the binary is located at lib/python3.13/site-packages/selenium/webdriver/common/selenium-manager, and it is correctly located by the bindings.

So, LGTM 👍

thanks.