PyPI release readiness for selenium-devtools-py #294

Activity

1. vishnuv688

   added

   selenium-devtools-pyPython Selenium adapter for the DevTools dashboardPython Selenium adapter for the DevTools dashboard

   on Aug 12, 2026
2. vishnuv688

   self-assigned this

   on Aug 12, 2026
3. vishnuv688

   added a parent issue on Aug 12, 2026

   • Epic: Python Selenium adapter for the DevTools dashboard #277
4. vishnuv688 commented on Sep 1, 2026

   

   vishnuv688

   on Sep 1, 2026

   Last edited by vishnuv688

   MemberAuthor

   More actions

   Release decisions from the maintainer review — settle before publishing

   Raised with @christian-bromann ahead of the first publish. One is agreed, three are open.

   1. Name — agreed ✅

   selenium-devtools-py, free on PyPI, no objections. Nothing to do beyond claiming it with the first publish.

   2. Node as a hard requirement — open ⚠️

   The wheel does not bundle the backend; it fetches @wdio/devtools-backend via npx, so Python users need Node 18+ (node_runtime.require_node checks and fails with a clear message).

   Feedback: "Seems awkward to make Python user require Node.js — if it is only the backend service we could bundle it into a binary? I guess a disadvantage then is that it makes the package 30+mb big."

   It is not only the dashboard. Python's trace export also routes through the backend, because #298 decided against re-implementing the ~3,100 lines of trace transforms per language. The JS adapters skip the backend in trace mode only because they already run on Node. So today a Python user without Node can produce neither a dashboard nor a trace — the requirement is broader than the question assumed.

   Measured, so the size trade-off is not a guess:

   	size
   packages/backend/dist	168 KB
   packages/app/dist (UI)	1.1 MB
   Node runtime (what a single-executable build embeds)	~90–115 MB uncompressed, by major version

   Our own payload is ~1.3 MB. The weight is entirely the runtime.

   Options:

   • (a) Status quo. Node 18+ required, checked up front with a clear error. Zero build machinery. Rejected by the maintainer as awkward, and it is the status quo only by default.
   • (b) Bundle a single executable. Removes the requirement. ~30–50 MB per compressed wheel — the 30+ MB estimate is right per wheel — but PyPI wheels are per-platform, so ~5 per release (macOS arm64/x64, Linux x64/arm64, Windows x64), plus a build matrix and a pure-Python sdist fallback. Ongoing maintenance surface, and worth checking against the PyPI project size quota.
   • (c) Node as an extra. pip install selenium-devtools-py stays ~100 KB and uses whatever Node is on PATH; pip install selenium-devtools-py[node] pulls a prebuilt Node wheel for users without one. Same end-user outcome as (b) with no binary matrix of ours to maintain. Needs verification — platform coverage and maintenance health of the available Node-binary wheels have not been checked.

   Recommendation: spike (c), fall back to (b). Not blocking until the decision is made, but it must be made before the first publish: moving from "needs Node" to "bundles Node" is additive, but the reverse is not.

   3. Secrets — none required ✅ (clarification)

   None are needed. .github/workflows/python-release.yml already uses PyPI trusted publishing — permissions: id-token: write, no token anywhere. What it does need, from someone with owner rights on the PyPI project:

   • A pending publisher registered for selenium-devtools-py, pointing at this repo, workflow filename python-release.yml, environment pypi
   • The same for testpypi, for the dry run
   • GitHub environments pypi and testpypi to exist (repo side — can be done here)

   4. Automated publish workflow — open ⚠️

   python-release.yml is workflow_dispatch today, deliberately mirroring release.yml for npm — which is also manual. Automating Python alone diverges the two.

   • Decide: automate both (fire on a published GitHub Release), or keep Python matching npm until both change together

   Before the first publish

   • Enable the pytest plugin from pytest's own config, not only an env var #339 — pytest CLI/ini config surface (changing how capture is switched on is breaking after release)
   • Node bundling decision (§2)
   • Pending publisher registered (§3)
   • TestPyPI dry run passes
   • Automation decision (§4)
5. vishnuv688

   closed this as completedon Sep 30, 2026