fix: allow Python 3.14 installation

[mikemikimike]

Related issue

Fixes #1348.

Background

The root project and rpaframework package declared Python support as <3.14, so pip rejected Python 3.14 installations even though the dependency set supports Python 3.14.

Changes

• Remove the <3.14 upper bound from the root and main package metadata.
• Advertise Python 3.13 and 3.14 support in the main package classifiers.
• Add an Ubuntu Python 3.14 job to the main package CI matrix.
• Remove the obsolete SETUPTOOLS_USE_DISTUTILS=stdlib override from the main and docs workflows.
• Regenerate the root and packages/main lock files after rebasing onto current master.

Compatibility

This expands the declared supported Python versions and does not change runtime behavior for existing Python versions. Removing the obsolete distutils override allows modern setuptools to build legacy source distributions on Python 3.14.

Verification

• uv lock — passed for the root project.
• uv lock — passed for packages/main.
• uv lock --check — passed for the root project.
• uv lock --check — passed for packages/main.
• uv sync --project packages/main --python C:\\Users\\mikemikimike\\AppData\\Local\\Programs\\Python\\Python314\\python.exe --dry-run — passed; resolved 170 packages and selected Python 3.14-compatible artifacts.
• TOML parsing with Python tomllib — passed.
• git diff --check — passed.

The full test suite was not run because the change is limited to package metadata, lock files, and CI environment configuration; the new Python 3.14 dependency resolution was validated with the dry-run install above.

[CLAassistant]

All committers have signed the CLA.

[mikahanninen]

Thanks for picking this up — the direction is right, and the <3.14 cap really is stale (nothing in main's dependency tree requires it; I resolved all 55 direct deps against 3.14 and got a clean 119-package resolution).

The ubuntu-py314 job you added did its job and found a real blocker, though. Here's the diagnosis.

Why the 3.14 job failed

× Failed to build `stringcase==1.2.0`
  ╰─▶ Call to `setuptools.build_meta:__legacy__.build_wheel` failed
      ModuleNotFoundError: No module named 'distutils'

The cause is not Python 3.14 or stringcase — it's SETUPTOOLS_USE_DISTUTILS: stdlib in the workflow env. distutils was removed from the standard library in Python 3.12, so forcing stdlib guarantees an import failure on 3.12+. setuptools has defaulted to local (its own vendored copy) since v60, which works fine.

Reproduction on Python 3.14 — same package, only the env var differs:

$ SETUPTOOLS_USE_DISTUTILS=stdlib uv pip install stringcase==1.2.0
ModuleNotFoundError: No module named 'distutils'

$ uv pip install stringcase==1.2.0
   Building stringcase==1.2.0
      Built stringcase==1.2.0
 + stringcase==1.2.0

So removing (or version-scoping) that env var should make the job pass. It's also set in .github/workflows/docs.yaml:19.

Two other things needed before this can merge

The lock files are stale. Both still record requires-python = ">=3.10, <3.14", so they contradict the pyproject change and uv lock --check fails:

$ uv lock --check                 # root
The lockfile at `uv.lock` needs to be updated, but `--check` was provided.
$ cd packages/main && uv lock --check
The lockfile at `uv.lock` needs to be updated, but `--check` was provided.

Without regenerating them, 3.14 still won't resolve, so #1348 wouldn't actually be fixed. You mentioned resolution stalled in your environment — happy to regenerate them if that's still blocking you.

This branch predates the security merge. Its merge-base is e8d1f1a, but master is now at 6e45621 (#1350, which bumped pillow/cryptography/pypdf and friends). Rebasing first means the regenerated locks pick up the patched versions rather than reverting them.

Related, but not for this PR

stringcase is pulled in transitively by O365, which is capped at <2.0.27 here. stringcase is sdist-only and was last released in 2017, so it always has to build from source. O365 2.1.9 dropped the dependency entirely — filed separately as a follow-up, since bumping across that minor needs an RPA.Email.Exchange API check and shouldn't ride along here.

Suggested scope for this PR: the metadata change you have, plus dropping SETUPTOOLS_USE_DISTUTILS, regenerated locks, rebased onto master.

[mikahanninen]

Small correction to my comment above: the O365 consumer is RPA.MSGraph, not RPA.Email.Exchange. Filed the follow-up as #1352 with the actual import surface.

[mikemikimike]

Verified and addressed the requested scope: rebased onto current master, removed SETUPTOOLS_USE_DISTUTILS=stdlib from the main and docs workflows, regenerated both lock files, and verified Python 3.14 resolution with uv sync --dry-run. The O365 upgrade remains out of scope as requested.