build(ray-tune): remove python version-specific dep requirements

[AlessandroPomponio]

Context

Earlier we had specific version requirements for numba and other packages to make sure certain Python versions weren't installing unsupported versions. This was added because we saw this happening multiple times in the CI.

Manual checks, though, show that this isn't happening anymore. Even specifiers that were added recently (e.g., for SciPy) aren't needed. This has been verified on a clean virtual environment with both uv pip and pip:

(.venv) alessandropomponio@MacBook-Pro-di-Alessandro ~/w/t/ado-3.14> uv pip install /Users/alessandropomponio/Documents/GitHub/public/ado/plugins/operators/ray_tune
Resolved 42 packages in 1.98s
      Built ado-ray-tune @ file:///Users/alessandropomponio/Documents/GitHub/public/ado/plugins/operators/ray_tune
Prepared 5 packages in 1.62s
Installed 42 packages in 412ms
 + ado-ray-tune==1.8.1.dev39+g56cf73b88 (from file:///Users/alessandropomponio/Documents/GitHub/public/ado/plugins/operators/ray_tune)
 + annotated-types==0.7.0
 + attrs==26.1.0
 + bayesian-optimization==1.4.0
 + certifi==2026.5.20
 + charset-normalizer==3.4.7
 + click==8.4.1
 + cma==4.4.4
 + directsearch==1.0.1
 + filelock==3.29.0
 + fsspec==2026.4.0
 + idna==3.17
 + joblib==1.5.3
 + jsonschema==4.26.0
 + jsonschema-specifications==2025.9.1
 + llvmlite==0.47.0
 + msgpack==1.1.2
 + nevergrad==1.0.12
 + numba==0.65.1
 + numpy==2.4.6
 + packaging==26.2
 + pandas==3.0.3
 + paretoset==1.2.5
 + protobuf==7.35.0
 + pyarrow==24.0.0
 + pydantic==2.13.4
 + pydantic-core==2.46.4
 + python-dateutil==2.9.0.post0
 + pyyaml==6.0.3
 + ray==2.55.1
 + referencing==0.37.0
 + requests==2.34.2
 + rpds-py==2026.5.1
 + scikit-learn==1.8.0
 + scipy==1.17.1
 + setuptools==82.0.1
 + six==1.17.0
 + tensorboardx==2.6.5
 + threadpoolctl==3.6.0
 + typing-extensions==4.15.0
 + typing-inspection==0.4.2
 + urllib3==2.7.0

(.venv) alessandropomponio@MacBook-Pro-di-Alessandro ~/w/t/ado-3.14> pip install /Users/alessandropomponio/Documents/GitHub/public/ado/plugins/operators/ray_tune
[...]
Installing collected packages: urllib3, typing-extensions, threadpoolctl, six, setuptools, rpds-py, pyyaml, pyarrow, protobuf, packaging, numpy, msgpack, llvmlite, joblib, idna, fsspec, filelock, click, charset_normalizer, certifi, attrs, annotated-types, typing-inspection, tensorboardX, scipy, requests, referencing, python-dateutil, pydantic-core, numba, cma, scikit-learn, pydantic, pandas, jsonschema-specifications, directsearch, paretoset, jsonschema, bayesian-optimization, ray, nevergrad, ado-ray-tune
Successfully installed ado-ray-tune-1.8.1.dev39+g56cf73b88 annotated-types-0.7.0 attrs-26.1.0 bayesian-optimization-1.4.0 certifi-2026.5.20 charset_normalizer-3.4.7 click-8.4.1 cma-4.4.4 directsearch-1.0.1 filelock-3.29.0 fsspec-2026.4.0 idna-3.17 joblib-1.5.3 jsonschema-4.26.0 jsonschema-specifications-2025.9.1 llvmlite-0.47.0 msgpack-1.1.2 nevergrad-1.0.12 numba-0.65.1 numpy-2.4.6 packaging-26.2 pandas-3.0.3 paretoset-1.2.5 protobuf-7.35.0 pyarrow-24.0.0 pydantic-2.13.4 pydantic-core-2.46.4 python-dateutil-2.9.0.post0 pyyaml-6.0.3 ray-2.55.1 referencing-0.37.0 requests-2.34.2 rpds-py-2026.5.1 scikit-learn-1.8.0 scipy-1.17.1 setuptools-82.0.1 six-1.17.0 tensorboardX-2.6.5 threadpoolctl-3.6.0 typing-extensions-4.15.0 typing-inspection-0.4.2 urllib3-2.7.0

[DRL-NextGen]

Checks Summary

Last run: 2026-06-02T09:32:15.125Z

Mend Unified Agent vulnerability scan found 2 vulnerabilities:

Severity	Identifier	Package	Details	Fix
🔷 Medium	CVE-2026-48710	starlette-0.52.1-py3-none-any.whl	Starlette is a lightweight ASGI framework/toolkit. Prior to version 1.0.1, the HTTP "Host" request h... Starlette is a lightweight ASGI framework/toolkit. Prior to version 1.0.1, the HTTP "Host" request header was not validated before being used to reconstruct "request.url". Because the routing algorithm relies on the raw HTTP path while "request.url" is rebuilt from the "Host" header, a malformed header could make "request.url.path" differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on "request.url" (rather than the raw "scope" path) could therefore be bypassed. Users should upgrade to a version greater than or equal to version 1.0.1, which validates the "Host" header against the grammar of RFC 9112 §3.2 / RFC 3986 §3.2.2 when constructing "request.url" and falls back to "scope["server"]" for malformed values.	Upgrade to version starlette - 1.0.1,starlette - 1.0.1,https://github.com/Kludex/starlette.git - 1.0.1
🔷 Medium	CVE-2026-45409	idna-3.14-py3-none-any.whl	This is the same issue as CVE-2024-3651, however the original remediation in 2024 was not a complete... This is the same issue as CVE-2024-3651, however the original remediation in 2024 was not a complete fix. Payloads such as ""\u0660" * N" or ""\u30fb" * N + "\u6f22"" utilize the "valid_contexto" function prior to length rejection, and for high values of "N" will take a long time to process. Impact A specially crafted argument to the "idna.encode()" function could consume significant resources. This may lead to a denial-of-service. Patches Starting in version 3.14, the function rejects long inputs as soon as practicable prior to any further processing to minimize resource consumption. In version 3.15, this approach was extended to lesser used alternate functions (i.e. per-label conversions and codec support). Workarounds Domain names cannot exceed 253 characters in length, if this length limit is enforced prior to passing the domain to the "idna.encode()" function it should no longer consume significant resources. This is triggered by arbitrarily large inputs that would not occur in normal usage, but may be passed to the library assuming there is no preliminary input validation by the higher-level application.	Upgrade to version idna - 3.15

[michael-johnston]

What are the risks?

[AlessandroPomponio]

In theory wheels should say what python versions they're compatible with, but I remember us having issues earlier on with numba.
To be fair, since the issue is only with python 3.14 because of autogluon, we could keep all the other specifiers and remove the 3.14 ones. We can then see what happens when resolving packages

[AlessandroPomponio]

@michael-johnston I checked and we are always resolving v0.62.1 for numba, so we don't need the old version specifiers now. I slightly updated the pyproject to make it a bit clearer