RPA Framework: a library collection where the package layout is the design

README.rst is assembled from the docs tree, not written by hand

The README is reStructuredText and it opens with two Sphinx directives before any prose: a contents block scoped to the local document with depth 1, and `.. include-docs-readme`, an extension directive that pulls a separate file in at build time. The repository root also holds a `docs/` directory, a `config/` directory and a `tasks.py`.

So the front page of the repository is a build target. The documentation group in pyproject.toml carries the toolchain that produces it: sphinx with sphinx-rtd-theme, plus sphinx-markdown-builder, sphinx-issues, sphinx-lint and robotframeworklexer, which is the point at which Robot Framework keyword documentation starts being checked by the same lint pass as prose. docutils, jinja2 and markupsafe are there for the template layer.

What that means for a reader is that the README and the site are one document in two forms, and edits to either go through the docs tree. The same split shows in the examples: `examples/README.md` and `examples/manipulating-pdf/` sit beside the library documentation rather than inside it.

Ten packages on PyPI, two of which ship no libraries

The package section is a wall of PyPI version badges, and the set is explicit: rpaframework, rpaframework-assistant, rpaframework-aws, rpaframework-core, rpaframework-google, rpaframework-hubspot, rpaframework-openai, rpaframework-pdf, rpaframework-recognition and rpaframework-windows.

Two of them are called out as support packages that on their own contain no libraries: rpaframework-core and rpaframework-recognition. That is worth holding on to, because the root metapackage still depends on rpaframework-recognition at 7.0.0 or newer. The libraries themselves live in the aggregate and in the per-provider packages.

The dependency list of that aggregate, named rpaframework-meta at version 0.0.1, is where the shape becomes clear: rpaframework 31.0.0 or newer, rpaframework-aws 7.0.0, rpaframework-google 11.0.0, rpaframework-hubspot 3.0.0, rpaframework-openai 4.0.0, rpaframework-recognition 7.0.0, rpaframework-windows 10.0.0, robotframework 5.0.1, robotframework-browser 17.2.0 and h11. Note that a browser automation stack is a hard dependency of the aggregate, whether or not you automate the web.

Which cloud you use decides which package you install

The library table encodes packaging decisions in its third column, where an x means the library ships inside the rpaframework package:

| `Cloud.AWS`_            | Use Amazon AWS services                    | x,aws                  |
| `Cloud.Azure`_          | Use Microsoft Azure services               | x                      |
| `Cloud.Google`_         | Use Google Cloud services                  | google                 |
| `Assistant`_            | Display information to a user and request input. | assistant         |
| `Browser.Selenium`_     | Control browsers and automate the web      | x                      |
| `Browser.Playwright`_   | Newer way to control browsers              | special (more below)   |

So Azure ships in the aggregate, AWS needs the separate aws package, Google needs the google package, and the Assistant library, which is how a robot asks a human for input, needs the assistant package. Cloud.Azure being the outlier is the kind of detail that breaks a script written from memory.

Browser.Playwright is the one row with no package name at all. Its cell reads special, with a pointer to a note further down, which means the rule for including the newer browser library is not in the table you read it in.

The metapackage raises floors on thirteen libraries

The root pyproject.toml carries a uv override list that reaches far past the project's own dependencies:

override-dependencies = [
	"h11>=0.16.0",
	"protobuf>=6.33.5",
	"pillow>=12.3.0",
	"cryptography>=50.0.0",
	"requests>=2.33.0",
	"PyJWT>=2.13.0",
	"pypdf>=6.15.0",
	"pyasn1>=0.6.4",
	"lxml>=6.1.0",
	"urllib3>=2.6.3",
	"msgpack>=1.2.1",
	"setuptools>=83.0.0",
	"httplib2>=0.32.0",
]

None of these is an RPA library. They are the shared dependencies underneath the PDF, image, crypto and HTTP paths, and the floors are high: cryptography 50, pillow 12.3, requests 2.33, setuptools 83. Installing the aggregate into an environment that already has applications is therefore a negotiation, not a local change.

This is the cost side of the packaging split. Taking the per-package route instead of the aggregate avoids most of it, and the individual package versions in the dependency list, rpaframework-aws 7.0.0 and the rest, suggest those floors travel with the aggregate rather than with each library.

Python below 3.14, and four macOS packages that need setuptools to build

The interpreter range is `>=3.10,<3.14`, an upper bound rather than a floor, so Python 3.14 is excluded outright while 3.10 is still supported. For a library that people pin in older automation estates that is a sensible choice, and it is also a hard stop for anyone who upgrades first.

The build section is more unusual. Four packages are given an explicit build dependency:

[tool.uv.extra-build-dependencies]
pyobjc-core = ["setuptools"]
pyobjc-framework-applicationservices = ["setuptools"]
pyobjc-framework-cocoa = ["setuptools"]
pyobjc-framework-quartz = ["setuptools"]

pyobjc is the bridge to macOS system frameworks, so on a Mac these four are compiled with setuptools supplied to them, and on other platforms the entries do nothing. It is a small, well-targeted fix for a class of build failure rather than a general policy.

The same file makes four packages resolve from the working tree instead of an index:

[tool.uv.sources]
rpaframework = { path = "packages/main", editable = true }
rpaframework-devutils = { path = "packages/devutils", editable = true }
rpaframework-recognition = { path = "packages/recognition", editable = true }
rpaframework-pdf = { path = "packages/pdf", editable = true }

A contributor therefore edits packages/main, packages/devutils, packages/recognition and packages/pdf in place, and nothing else in the workspace is editable. rpaframework-pdf appears here but not in the aggregate dependency list, which means the PDF libraries reach the aggregate through rpaframework itself.

The visible library table stops in the middle of the alphabet

The library table is the heart of the README, and the version in the repository ends inside it. The rows that are there run Archive for TAR and ZIP files, Assistant, Browser.Selenium, Browser.Playwright, Calendar for date and time manipulations, Cloud.AWS, Cloud.Azure, Cloud.Google, and then Crypto, described as common hashing and encryption operations, after which the table's rule line is cut in half and the document ends.

That leaves two gaps a reader will notice. The libraries alphabetically after Crypto are not enumerated here at all, and the note that the Browser.Playwright row points to, marked as coming further below, is not in the document either. The library that automates the newer way of controlling browsers is therefore the one whose packaging rule you cannot read from the repository.

The documentation site at rpaframework.org is where that rule and the rest of the catalog live, along with the release notes and the RSS feed the README links to. Nothing in the repository claims the table is complete at the point where it stops.

The newest releases belong to a package neither list mentions

Three releases carry 2026-08-23 and they were published twelve minutes apart: rpaframework-pdf 11.0.2, rpaframework-recognition 8.0.2 and rpaframework-sema4ai 1.1.1. The last push to the default branch, master, was 2026-08-29, six days after those tags.

Two of the three are visible in the README package badges. The third is not. rpaframework-sema4ai appears in neither the ten-package badge list nor the metapackage dependency list, and no library table row names it, because the table ends earlier. It is a release line you only find by looking at the tags.

The other project signals are conventional: a single LICENSE file at the root with Apache-2.0 in the metadata and a PyPI badge pointing at the Apache text, .github/ for workflows, a CLAUDE.md file and a .claude/ directory at the root, and uv.lock for reproducible resolution. The project's own framing is that it is sponsored by Robocorp, optimized for Robocorp Control Room and Developer Tools, and open to external contributions.

Editorial conclusion

Use RPA Framework when you are already automating on Robot Framework and want the same call shape across clouds, and install the aggregate only if you intend to use most of it, because it brings robotframework-browser and thirteen raised dependency floors with it. Skip it if your environment cannot take cryptography 50, pillow 12.3 or requests 2.33, or if you need a Python newer than 3.13. Before you commit, check the packaging rule for Browser.Playwright and the contents of rpaframework-sema4ai, since neither the README package list nor the metapackage dependencies cover them, and both answers live outside the repository.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. robocorp/rpaframework on GitHub