O365 capped at <2.0.27 pulls in stringcase, an unmaintained 2017 sdist that breaks on Python 3.12+

[mikahanninen]

Target components

main (RPA.MSGraph)

What is wrong

rpaframework caps O365 at >=2.0.21,<2.0.27. That range resolves to o365 2.0.26, which depends on stringcase — a package that is:

• sdist-only (no wheel), so it must be built from source on every install
• last released 2017-08-06, unmaintained since
• reliant on distutils, which was removed from the standard library in Python 3.12

The result is an install failure on modern Pythons:

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

O365 2.1.9 dropped the stringcase dependency entirely. Lifting the cap removes the problem dependency at the source, rather than depending on a 2017 sdist continuing to build.

This is not new

• Fail to install rpaframework in Windows 10 Pro #1148 (Feb 2024) is the same root cause — Collecting stringcase>=1.2.0 (from O365<2.0.27,>=2.0.21->rpaframework) → ModuleNotFoundError: No module named 'distutils'. Closed as not planned.
• It resurfaced in the Python 3.14 CI job on fix: allow Python 3.14 installation #1351.

Users have been hitting this for over two years.

Note: this is not the only 3.14 blocker

The CI failure on #1351 is primarily caused by SETUPTOOLS_USE_DISTUTILS: stdlib in the workflow env — forcing the removed stdlib distutils on 3.12+. With that variable unset, stringcase builds fine even on 3.14:

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

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

So removing that env var unblocks CI. This issue is the durable fix: an unmaintained 2017 sdist in the dependency tree will keep causing trouble, and end users installing from PyPI do not benefit from a CI-only workaround.

Suggested change

- "O365>=2.0.21,<2.0.27",
+ "O365>=2.1.9",

then uv lock --upgrade-package o365 in packages/main.

Why this needs care rather than a drive-by bump

2.0.26 → 2.1.9 crosses a minor version, and RPA.MSGraph imports a fairly wide surface that should be checked for drift:

from O365 import (
    Account, MSGraphProtocol, FileSystemTokenBackend,
    directory, drive as drive_module, sharepoint,
)
from O365.utils import Token, BaseTokenBackend
from O365.utils.utils import (
    ME_RESOURCE, USERS_RESOURCE, GROUPS_RESOURCE, SITES_RESOURCE,
)

RPA.MSGraph tests would need to pass, and the O365.utils.utils imports in particular are internal-ish and the most likely to have moved.

System info

• Affected: rpaframework (all versions in the O365<2.0.27 range)
• Blocks: Python 3.12+ installs where a wheel cannot be used; contributes to Cannot install rpaframework - Python 3.14 #1348