Robot Framework: Where the Example Stops, Where the Versions Stop, and What setup.py Will Refuse to Build

The one example test imports a resource file you do not have

The example on the front page is the project's clearest teaching example and its least runnable one. It is a suite with a single test for valid login, and its settings block carries documentation saying the workflow is created using keywords in the imported resource file, followed by a single Resource entry pointing at `login.resource`. The test case named Valid Login then calls `Open Browser To Login Page`, `Input Username` with the value demo, `Input Password` with the value mode, `Submit Credentials`, and `Welcome Page Should Be Open`, closing with a `[Teardown]` that calls `Close Browser`.

Five keyword calls, none of them defined here, and no library import anywhere in the suite. That is a deliberate separation of concerns and a real first-runner obstacle at the same time. The framework is a keyword execution engine and the keywords are the part you choose or write yourself. Expect your first real task to be writing login.resource, and budget for it as part of the work rather than as setup you can skip.

Options come before the path, and the path can be a directory

Execution is a command line, and the argument shape has one rule that bites scripted callers. Options go before the path:

robot tests.robot
robot --variable BROWSER:Firefox --outputdir results path/to/tests/

Three things follow from those two lines. A bare path can be a single file or a directory, so a run does not need an explicit recursive flag to sweep a tree. Variables use colon syntax rather than equals, as in `BROWSER:Firefox` in the README example. And anything that generates a command line has to place flags ahead of the target, because a flag sitting after the path is no longer a flag in this syntax. The second line also shows the artifact story: `--outputdir results` decides where output lands, and that location is what the second tool consumes. Combining and post-processing runs is a separate program:

rebot --name Example output1.xml output2.xml

rebot reads the XML results and rewrites them, so a CI setup is really two stages, and rebot has to know the directory the first stage wrote to. Both tools carry their own help output, `robot --help` and `rebot --help`.

Python 3.8 is the floor, and older runtimes inherit older ceilings

The support story is a ladder rather than a single requirement, and each rung carries a different version of the framework. The stated requirement is Python 3.8 or newer, and the framework also runs on PyPy. For anyone on Python 3.6 or 3.7, the answer is Robot Framework 6.1.1, which is the latest version supporting them. For anyone on Python 2, Jython, or IronPython, the answer is Robot Framework 4.1.3. Read that as a maintenance boundary rather than a footnote. An organization still running its test suite on 3.7 is not choosing an old framework for preference reasons; it is choosing between 6.1.1 and an unsupported installation, and 6.1.1 sits one major line behind the current 7.5. A Jython or IronPython shop is further back still, on a release line that predates the current major by three. The practical consequence is that your framework version is dictated by your CI runtime before anyone argues about test authoring style. If you are evaluating this now, establish your oldest supported interpreter first, then look up which ceiling that leaves you, and treat any feature discussion on 7.5 as inapplicable if the answer came back 6.1.1. The install itself is a single command, assuming Python and pip are already present.

The classifiers reach Python 3.15 while the formatter stops at 3.13

The declared support matrix and the tooling configuration do not agree, and the disagreement is visible in the repository. The packaging classifiers in setup.py enumerate interpreters from 3.8 through 3.9, 3.10, 3.11, 3.12, 3.13, 3.14, and 3.15, alongside both CPython and PyPy implementations, with a Development Status of 5, Production/Stable. Meanwhile the Black configuration in pyproject.toml sets line_length 88 and a target-version list that starts at py38 and stops at py313, and the Ruff configuration sets target-version to py38. A comment in pyproject.toml notes that the Black target versions and Ruff's target-version should be removed once a [project] table with requires-python is added. Ruff also carries per-file overrides at py312 for five specific paths, including src/robot/running/arguments/typealiasresolver.py and src/web/libdoc/DevLibrary.py. Formatter target versions control compatible output syntax; they do not establish runtime support or test results. Check the project’s test matrix when evaluating interpreter compatibility.

setup.py already carries 7.5.1.dev1 while the newest release is 7.5

The version on the default branch is ahead of anything you can install. The packaging script declares `VERSION = "7.5.2.dev1"`, while the newest release is Robot Framework 7.5.1 published on 2026-11-02, preceded by 7.5 on 2026-09-14 and release candidate 1 on 2026-09-04. Note that the version string is a plain constant in setup.py, with a comment explaining it is updated by running `invoke set-version <version>` and pointing at tasks.py for details. The consequence for consumers is the ordinary one but worth stating plainly: `pip install robotframework` gives you a published release, not 7.5.2.dev1, and the development marker is not a published release you can depend on. If you want behaviour that only exists on master you are building from source, and the repository does support that path, with rundevel.py at the root for running against a working copy and BUILD.rst describing the build. Two directories, atest/ and utest/, carry acceptance and unit tests respectively, and .git-blame-ignore-revs is present so that large reformatting commits can be excluded from blame.

Renaming a document in README.rst breaks the build

The packaging script contains a guard that is easy to trip without knowing it exists. It reads README.rst into the long description, then loops over two names, INSTALL and CONTRIBUTING. For each one it builds a relative reference string, checks whether that string appears in the file, and raises RuntimeError naming the missing reference if it does not. When the reference is found, it replaces it with a form pointing at the GitHub blob URL for that document on the master branch. The reason is that relative document references do not survive being rendered on PyPI, so the script rewrites the two cross-references that matter for installation and contribution. Everything else in that long description is passed through untouched. Two consequences. First, this is a hard build failure, not a warning, and it fires on the packaging path rather than on a test, so a documentation edit that removes or renames a reference to INSTALL.rst or CONTRIBUTING.rst breaks a release with an error about a string not found in README.rst. Second, the PyPI page for the project is a rendered copy of the README with those two links rewritten, so anyone who needs the detailed installation instructions is being sent to the master branch of the repository rather than to the released source tree.

Three licenses and a trademark, split across code, docs, and ecosystem

The licensing paragraph is short and it does more work than its length suggests. The framework itself is open source software provided under the Apache License 2.0. Documentation and other similar content use the Creative Commons Attribution 3.0 Unported license. And most libraries and tools in the ecosystem are also open source, but they may use different licenses. That third clause is the one to sit with, because the ecosystem is where your actual test capability comes from. The framework description puts it plainly: the rich ecosystem around it consists of various generic libraries and tools developed as separate projects. Keyword implementations, browser drivers, and the bindings that make a suite like the login example run at all come from elsewhere and carry their own terms, so a license audit of a Robot Framework installation is an audit of your dependency set, not of this repository. Ownership sits with a non-profit entity too. The Robot Framework trademark is owned by the Robot Framework Foundation, which also sponsors development, and the project asks users who benefit from the framework to consider joining the foundation to help maintain it and develop it further.

Editorial conclusion

Robot Framework fits a team that wants readable, reviewable test and task files in plain text, runs on CPython or PyPy, and is willing to select its libraries separately since the framework ships none of the browser or driver integrations itself. Do not pick it on the assumption that a new interpreter works out of the box: verify your runtime against the stated Python 3.8 floor, and if you are on 3.6, 3.7, Jython, IronPython, or Python 2, the ceiling you inherit is 6.1.1 or 4.1.3 rather than 7.5. Before adopting, read three things yourself. Read the User Guide for option syntax, because the only command forms shown are a path with options placed before it and a rebot invocation, which is not enough to script safely. Read the license split, since Apache 2.0 covers the code, Creative Commons Attribution 3.0 Unported covers the documentation, and the ecosystem libraries carry their own terms. And decide whether the Foundation's trademark and sponsorship arrangement suits an organisation that may want its own brand on the tooling.

Frequently asked questions

Official sources

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