Python Environment, Installation, CLI, Editors, and First Suite: Core Concepts and Mental Model

1. The environment problem: the command name is not the runtime

Chapter 01 established that reliable automation needs explicit ownership: the suite, keyword layers, external state, and result artifacts must be distinguishable. The same rule applies before a single suite can execute. A command such as robot tests looks simple, but it hides several decisions: which Python interpreter owns the installed package, which environment contains that package, which launcher the shell resolves, which working directory Robot receives, and where the result files are written.

Many workstation failures are therefore not Robot syntax failures at all. A developer may install Robot Framework with one Python and launch robot from another environment. An editor may analyze the project with a third interpreter. A green local run may rely on a globally installed package that a clean CI runner does not have. The purpose of this chapter is to make these relationships observable and reproducible.

2. Mental model: interpreter ownership to result ownership

flowchart TD
P[Python interpreter] --> V[Isolated environment]
V --> D[pip or uv dependency install]
D --> R[robotframework package]
R --> E[robot console launcher]
R --> M[python -m robot]
E --> S[Parsed .robot suite]
M --> S
S --> X[Execution]
X --> O[Explicit output directory]
O --> XML[output.xml]
O --> LOG[log.html]
O --> REP[report.html]

The interpreter is the root of the chain. A virtual environment is a directory containing an interpreter context and environment-specific installed packages. Installing robotframework into that environment creates Python modules and console entry points. The robot launcher is convenient, but the shell chooses it through PATH. By contrast, python -m robot asks a specific Python interpreter to load Robot Framework as a module. The two routes should converge on the same installed package when the environment is correctly wired.

The final state store in this chain is the output directory. Robot Framework generates output.xml as structured execution data and normally creates log.html and report.html from that result. Those artifacts belong to the run, not to the Python environment. Keeping environment state and run evidence separate makes rebuilds and diagnostics safer.

3. Define the objects before installing anything

4. Read-only provenance checks

Before creating or changing an environment, inspect what the current shell means by python, pip, and robot. Do not infer interpreter ownership from the command name alone.

Cross-platform Python checks

python --version
python -c "import sys; print(sys.executable); print(sys.prefix)"
python -m pip --version
python -m pip show robotframework
python -m robot --version

If Robot Framework is not installed into that interpreter, python -m robot --version will fail. That is useful evidence: it says the selected interpreter does not contain the package. It does not mean the source suite is broken.

PowerShell launcher resolution

Get-Command python -ErrorAction SilentlyContinue
Get-Command pip -ErrorAction SilentlyContinue
Get-Command robot -ErrorAction SilentlyContinue

POSIX shell launcher resolution

command -v python || true
command -v pip || true
command -v robot || true

The important comparison is not whether all three commands exist. It is whether the interpreter used to install Robot Framework is the same interpreter used to execute the suite. Chapter 04-level troubleshooting later goes deeper into import graphs; here the provenance chain is the focus.

5. Why an isolated environment is the default project boundary

A project-local virtual environment prevents one Robot Framework course project from silently depending on packages installed for another. It also gives the editor and the CLI a shared interpreter target. The environment directory itself should normally remain uncommitted because it contains platform-specific executables and paths; the reproducible input is the dependency declaration or lock data.

Activation is only a shell convenience. It modifies environment variables such as PATH so commands resolve into the environment. The environment still exists when it is not activated. For diagnostics and checkpoint runs, this chapter often calls the environment's Python executable by path so interpreter ownership remains visible.

6. robot versus python -m robot

Production teams can choose any of these forms. The invariant is that the choice must be reproducible and observable. A CI command that only succeeds because a developer previously activated a shell manually is not reproducible.

7. Result directories are part of the execution contract

Without an explicit output directory, generated artifacts can land in whichever working directory launched Robot. That makes local runs hard to compare and CI artifact collection fragile. The chapter therefore uses an explicit path for every meaningful run:

python -m robot --outputdir results/run-01 tests

Relative paths are meaningful only in the context of the process working directory. Record that directory when diagnosing path surprises:

from pathlib import Path
print(Path.cwd())

The output directory is evidence, not a cache to delete automatically when a run fails. Preserve first-failure artifacts until the cause is understood.

8. The editor is an optional productivity layer

RobotCode can provide language-server features, test discovery, execution, and debugging, but it does not replace the project environment or CLI contract. Current RobotCode documentation requires Python 3.10 or newer and Robot Framework 5.0 or newer. That means a Python 3.8 environment can be valid for Robot Framework 7.4.2 while being unsuitable for the current RobotCode runtime.

Prefer selecting the project's interpreter through the editor's supported environment-selection workflow. Do not commit a personal absolute interpreter path such as C:\Users\name\... or /home/name/.... A teammate and CI runner should be able to recreate the project without your workstation path.

9. Why this matters in DevOps

CI/CD starts from a clean or controlled runtime. A reproducible Robot project therefore needs enough evidence to answer four questions: Which Python executed? Which Robot Framework version was installed? Which source was selected? Where are the result artifacts? If any answer depends on a developer's shell history or editor state, the environment contract is incomplete.

Chapter 02 turns those answers into executable conventions. Later CI/container chapters reuse the same contract rather than inventing a second environment model.

10. Knowledge check

11. Summary and next step

The environment chain is Python interpreter → isolated environment → dependency installation → Robot Framework package → launcher/module invocation → suite execution → explicit result directory. Each link has distinct ownership and evidence. Lesson 2 builds this chain from an empty directory and runs the first pinned suite.

Further reading and current primary references

Version-sensitive statements in this lesson were checked on 2026-08-30. The mandatory path pins Robot Framework 7.4.2, the current stable release at the time of authoring. Robot Framework 7.5b1 is a pre-release and is not required. Robot Framework itself requires Python 3.8+; the current RobotCode toolchain has a stricter Python 3.10+ runtime requirement, so editor compatibility must be checked separately from framework compatibility.

• Robot Framework on PyPI — installation, Python requirement, release history
• Robot Framework 7.4.2 User Guide
• Robot Framework 7.4.2 release notes
• Python documentation — venv
• pip User Guide
• uv documentation — virtual environments
• RobotCode — current getting-started and environment guidance
• RobotCode project — current runtime requirements and configuration model
• External Testdoc — replacement for the deprecated built-in Testdoc