Python Environment, Installation, CLI, Editors, and First Suite: Configuration, Design Patterns, and Trade-Offs

1. Configuration choices solve different problems

Environment tooling is often debated as if one command determines project quality. It does not. The important design questions are: Who chooses Python? Where are dependencies declared? Are resolved versions reproducible? Which command is authoritative locally and in CI? What editor configuration is shared, and what remains personal?

This lesson compares those decisions without requiring learners to install every tool. The mandatory path remains the standard-library venv plus pip because it is available wherever supported Python is available.

2. Standard venv versus uv-managed environments

Current uv documentation creates a default .venv with uv venv and can install an exact package with uv pip install 'robotframework==7.4.2'. In project mode, uv run checks that the environment is synchronized with project/lock data before execution. Those are useful properties, but they do not change Robot Framework's own execution semantics.

# Optional alternative, not required for the chapter
uv venv
uv pip install 'robotframework==7.4.2'
uv run --with 'robotframework==7.4.2' robot --version

Do not mix low-level and project-managed uv workflows casually. If a team adopts uv project mode, follow uv's project dependency commands and lockfile conventions rather than manually mutating the managed environment.

3. Global install versus project isolation

A global Robot Framework install can be convenient for one-off personal experiments, but it creates hidden coupling between unrelated projects. Upgrading one global package may change all projects at once. It also weakens CI reproducibility because a clean runner starts without that workstation history.

Do not treat pip install --user or a machine-wide robot launcher as a project dependency strategy.

4. Exact pins versus compatible ranges

This course pins robotframework==7.4.2 because a teaching lab should behave the same next week and because the current pre-release must not be pulled accidentally. Product projects may choose compatible ranges during dependency declaration, but deployment or CI should still have a resolved, reviewable version set.

Never use a pre-release in a mandatory lab unless the lesson explicitly targets that pre-release and provides a stable fallback.

5. python -m robot versus the robot launcher

For local development inside an activated environment, robot is concise and conventional. For diagnostics, bootstrap scripts, and documentation that must prove interpreter ownership, python -m robot is clearer. CI can use either, provided the job constructs the environment deterministically and records versions.

A useful production convention is to make one repository command authoritative—perhaps a Make target, task runner command, PowerShell script, or documented module invocation—then have editors and CI call the same underlying command or configuration rather than duplicating flags independently.

6. IDE convenience versus CLI reproducibility

Editor integrations can discover tests, provide completion, linting, navigation, debug execution, and environment selection. They should not create a second invisible configuration universe. The learner should always be able to leave the editor, open a clean shell, recreate the environment, and run the same suite.

Current RobotCode encourages selecting a Python environment rather than hard-coding an extension-specific absolute interpreter path. Keep machine-specific paths out of shared repository configuration.

7. Committed configuration versus local-only settings

8. Tool deprecations belong in environment design

Robot Framework 7.4.2 deprecated the built-in Testdoc tool in favor of the enhanced external Testdoc project. The built-in implementation still works in 7.4.2, but the release notes state that deprecation warnings begin in 7.5 and removal is planned for Robot Framework 8.0. New course workflows should therefore avoid building automation around the built-in Testdoc command.

This is a broader lesson: environment design must track not only the core framework version but also tool lifecycle. A pinned environment can be perfectly reproducible and still be strategically obsolete if it pins a deprecated workflow forever.

9. Worked decision table

10. Security and privacy implications

Package indexes, proxy configuration, editor settings, and shell histories can carry credentials. Do not place private-index tokens in requirements.txt, example URLs, or command history. Avoid publishing absolute home-directory paths in logs when they expose usernames or internal directory structure. Result artifacts can also capture arguments and environment-derived values; Chapter 23 treats secrets in depth.

The environment itself should be replaceable. If a dependency installation is suspected of tampering or corruption, recreating the isolated environment from reviewed dependency inputs is safer than manually editing installed files.

Environment choices also affect evidence handling: regardless of whether the run is launched through venv, uv, an editor, or CI, keep output.xml, log.html, and report.html in an explicit result location so tool choice does not change the evidence contract.

11. Knowledge check

12. Summary and next step

Choose environment tools by invariants: explicit interpreter, isolated dependencies, reviewable version inputs, reproducible execution, portable editor configuration, and retained artifacts. Lesson 4 uses those invariants to diagnose command, interpreter, path, permission, encoding, and CI-portability failures without guessing.

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