[py] Loosen dependency specifiers in package config

[cgoldberg]

User description

💥 What does this PR do?

This PR loosens the dependency specifiers used in Python packaging configuration.

Since Selenium is a library used in various projects, we can't force specific versions of our dependencies on users because it might conflict with different versions of the same packages they use with other libraries. However, we want to ensure the selenium package still works with some range of declared dependencies, and not just let it pull in possibly incompatible dependencies on installation. There is no perfect solution for this.

Currently we use the "compatible release" specifier for Python package dependencies, which allows new dependency versions within the same minor version. Based on user feedback, this seems to be too strict. This PR changes the dependency specifications to use a minimum and maximum version instead, with the maximum being the next major version.

This will allow more installation flexibility, while (hopefully) not pulling in new dependency versions that introduce breaking changes (major version upgrades).

💡 Additional Considerations

Going forward, we would raise the minimum version occasionally with new releases. For CI and development, we will continue to pin a specific version via requirements.txt.

🔄 Types of changes

• Build/Packaging

---

PR Type

Other

---

Description

• Changed dependency specifiers from compatible release (~=) to minimum/maximum version ranges

• Updated trio, trio-websocket, typing_extensions, and websocket-client version constraints

• Allows more installation flexibility while preventing major version conflicts

---

Diagram Walkthrough

flowchart LR
  A["Compatible Release Specifiers"] -- "Replace with" --> B["Min/Max Version Ranges"]
  B --> C["More Installation Flexibility"]
  B --> D["Prevent Major Version Conflicts"]

Loading

File Walkthrough

Relevant files

Configuration changes

BUILD.bazel Update Bazel wheel dependency constraints                                py/BUILD.bazel Updated dependency version specifiers in Bazel wheel configuration Changed from compatible release (~=) to minimum/maximum version ranges Applied to trio, trio-websocket, typing_extensions, and websocket-client +4/-4      pyproject.toml Update pyproject dependency constraints                                    py/pyproject.toml Updated dependency version specifiers in Python project configuration Changed from compatible release (~=) to minimum/maximum version ranges Applied to trio, trio-websocket, typing_extensions, and websocket-client +4/-4

---

[qodo-merge-pro]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	✅ Fix broken version specifier Suggestion Impact: The commit added the missing comma, fixing the malformed version specifier exactly as suggested. code diff: - "websocket-client>=1.8.0<2.0", + "websocket-client>=1.8.0,<2.0", The version specifier is invalid due to a missing comma between the lower and upper bounds. This will break dependency parsing and resolution. Add a comma to separate the specifiers. py/BUILD.bazel [335] -"websocket-client>=1.8.0<2.0", +"websocket-client>=1.8.0,<2.0", [Suggestion processed] Suggestion importance[1-10]: 10 __ Why: The suggestion correctly identifies a malformed version specifier for websocket-client that lacks a comma, which would break dependency resolution, making this a critical fix.	High
	✅ Correct malformed dependency range Suggestion Impact: The commit added the missing comma, correcting the dependency specifier to "websocket-client>=1.8.0,<2.0". code diff: - "websocket-client>=1.8.0<2.0", + "websocket-client>=1.8.0,<2.0", The dependency constraint is malformed because it lacks a comma between specifiers, violating PEP 508. Insert the comma to ensure valid parsing by build tools. py/pyproject.toml [34] -"websocket-client>=1.8.0<2.0", +"websocket-client>=1.8.0,<2.0", [Suggestion processed] Suggestion importance[1-10]: 10 __ Why: The suggestion correctly identifies a malformed dependency constraint for websocket-client that violates PEP 508 and would break dependency installation, making this a critical fix.	High
Update

[shbenzer]

LGTM, no CVE for these ranges

[navin772]

This looks good and works for our case.
I don't know much but is mentioning non-released version limits as deps a common practice?

[nvborisenko]

Does it mean I am not be able to upgrade websocket-client package to the latest v2.0 if I really want to use it despite the fact that selenium requires <2.0? Let's say I know what I am doing and I am aware about incompatibility topic. This limitation is kind of recommendation or hard restriction?

[cgoldberg]

is mentioning non-released version limits as deps a common practice?

For upper limits, yes that's common practice.

[cgoldberg]

Does it mean I am not be able to upgrade websocket-client package to the latest v2.0

This means that during Selenium installation, it will never download and install 2.0+ for you. Once installation is complete, you can upgrade websocket-client to whatever version you want and selenium will attempt to use it at runtime.