tox configuration can be split into two categories: core and environment specific. Core settings are options that can be set once and used for all tox environments, while environment options are applied to the given tox environment only.
Out of box tox supports three configuration locations prioritized in the following order:
tox.ini,pyproject.toml,setup.cfg.
With regards to the configuration format, at the moment we only support ini-style. tox.ini and setup.cfg are by nature such files, while in pyproject.toml currently you can only inline the ini-style config.
Note that setup.cfg requires the content to be under the tox:tox and testenv sections and is otherwise ignored. pyproject.toml on the other hand is in TOML format. However, one can inline the ini-style format under the tool.tox.legacy_tox_ini key as a multi-line string.
The core settings are under the tox section while the environment sections are under the testenv:{env_name} section. All tox environments by default inherit setting from the testenv section. This means if tox needs an option and is not available under testenv:{env_name} will first try to use the value from testenv, before falling back to the default value for that setting. For example:
[tox]
min_version = 4.0
env_list =
py310
py39
type
[testenv]
deps = pytest
commands = pytest tests
[testenv:type]
deps = mypy
commands = mypy srcThe core settings are under the tox:tox section while the environment sections are under the testenv:{env_name} section. All tox environments by default inherit setting from the testenv section. This means if tox needs an option and is not available under testenv:{env_name} will first try to use the value from testenv, before falling back to the default value for that setting. For example:
[tox:tox]
min_version = 4.0
env_list =
py310
py39
type
[testenv]
deps = pytest
commands = pytest tests
[testenv:type]
deps = mypy
commands = mypy srcYou can inline a tox.ini style configuration under the tool.tox section and legacy_tox_ini key.
Below you find the specification for the ini-style format, but you might want to skim some examples first and use this page as a reference.
[tool.tox]
legacy_tox_ini = """
[tox]
min_version = 4.0
env_list =
py310
py39
type
[testenv]
deps = pytest
commands = pytest tests
[testenv:type]
deps = mypy
commands = mypy src
"""Specify a list of 508 compliant dependencies that must be satisfied in the Python environment hosting tox when running the tox command. If any of these dependencies are not satisfied will automatically create a provisioned tox environment that does not have this issue, and run the tox command within that environment. See provision_tox_env for more details.
[tox]
requires =
tox>4
virtualenv>20.2A string to define the minimal tox version required to run. If the host's tox version is less than this, it will automatically create a provisioned tox environment that satisfies this requirement. See provision_tox_env for more details.
Name of the tox environment used to provision a valid tox run environment.
3.23.0
When tox is invoked with the --no-provision flag, the provision won't be attempted, tox will fail instead.
A list of environments to run by default (when the user does not specify anything during the invocation).
3.4.0
Which tox environments are run during the tox invocation can be further filtered via the operating system environment variable TOX_SKIP_ENV regular expression (e.g. py27.* means don't evaluate environments that start with the key py27). Skipped environments will be logged at level two verbosity level.
Setting this to true will force tox to return success even if some of the specified environments were missing. This is useful for some CI systems or when running on a developer box, where you might only have a subset of all your supported interpreters installed but don't want to mark the build as failed because of it. As expected, the command line switch always overrides this setting if passed on the invocation. Setting it to config means that the value is read from the config file.
The root directory for the tox project (where the configuration file is found).
Directory for tox to generate its environments into, will be created if it does not exist.
Directory where to put tox temporary files. For example: we create a hard link (if possible, otherwise new copy) in this directory for the project package. This ensures tox works correctly when having parallel runs (as each session will have its own copy of the project package - e.g. the source distribution).
Flag indicating to perform the packaging operation or not. Set it to true when using tox for an application, instead of a library.
Default name of the virtual environment used to create a source distribution from the source tree.
Indicates where the packaging root file exists (historically setup.py file or pyproject.toml now).
A mapping of label names to environments it applies too. For example:
[tox]
labels =
test = py310, py39
static = flake8, mypy3.1.0
tox allows setting the Python version for an environment via the basepython setting. If that's not set tox can set a default value from the environment name (e.g. py310 implies Python 3.10). Matching up the Python version with the environment name has became expected at this point, leading to surprises when some configs don't do so. To help with sanity of users, an error will be raised whenever the environment name version does not match up with this expectation.
Furthermore, we allow hard enforcing this rule by setting this flag to true. In such cases we ignore the base_python and instead always use the base Python implied from the Python name. This allows you to configure base_python in the base section without affecting environments that have implied base Python versions.
The name of the tox environment.
Directory assigned to the tox environment. If not absolute it would be treated as relative to tox_root.
A folder that is always reset at the start of the run.
A folder containing log files about tox runs. It's always reset at the start of the run. Currently contains every process invocation in the format of <index>-<run name>.log, and details the execution request (command, environment variables, current working directory, etc.) and its outcome (exit code and standard output/error content).
Run on platforms that match this regular expression (empty means any platform). If a non-empty expression is defined and does not match against the sys.platform string the entire test environment will be skipped and none of the commands will be executed. Running tox -e <platform_name> will run commands for a particular platform and skip the rest.
Environment variables to pass on to the tox environment. The values are evaluated as UNIX shell-style wildcards, see fnmatch If a specified environment variable doesn't exist in the tox invocation environment it is ignored. The list of environment variable names is not case sensitive, for example: passing A or a will pass through both A and a.
A dictionary of environment variables to set when running commands in the tox environment. Lines starting with a file| prefix define the location of environment file.
Note
Environment files are processed using the following rules:
- blank lines are ignored,
- lines starting with the
#character are ignored,- each line is in KEY=VALUE format; both the key and the value are stripped,
- there is no special handling of quotation marks, they are part of the key or value.
If set to
Truethe content of the output will always be shown when running in parallel mode.
Always recreate virtual environment if this option is true, otherwise leave it up to tox.
Each line specifies a command name (in glob-style pattern format) which can be used in the commands section even if it's located outside of the tox environment. For example: if you use the unix rm command for running tests you can list allowlist_externals=rm or allowlist_externals=/usr/bin/rm. If you want to allow all external commands you can use allowlist_externals=* which will match all commands (not recommended).
A list of labels to apply for this environment. For example:
[testenv]
labels = test, core
[testenv:flake8]
labels = mypyWhen an interrupt is sent via Ctrl+C or the tox process is killed with a SIGTERM, a SIGINT is sent to all foreground processes. The suicide_timeout gives the running process time to cleanup and exit before receiving (in some cases, a duplicate) SIGINT from tox.
When tox is interrupted, it propagates the signal to the child process after suicide_timeout seconds. If the process still hasn't exited after interrupt_timeout seconds, its sends a SIGTERM.
When tox is interrupted, after waiting interrupt_timeout seconds, it propagates the signal to the child process, waits interrupt_timeout seconds, sends it a SIGTERM, waits terminate_timeout seconds, and sends it a SIGKILL if it hasn't exited.
Inherit missing keys from these sections.
The tox execute used to evaluate this environment. Defaults to Python virtual environments, however may be overwritten by plugins.
A short description of the environment, this will be used to explain the environment to the user upon listing environments.
tox environments that this environment depends on (must be run after those).
Warning
depends does not pull in dependencies into the run target, for example if you select py310,py39,coverage via the -e tox will only run those three (even if coverage may specify as depends other targets too -such as py310, py39, py38). This is solely meant to specify dependencies and order in between a target run set.
Commands to run before running the commands. All evaluation and configuration logic applies from commands.
The commands to be called for testing. Only execute if commands_pre succeed. Each line is interpreted as one command; however a command can be split over multiple lines by ending the line with the \ character.
Commands will execute one by one in sequential fashion until one of them fails (their exit code is non-zero) or all of them succeed. The exit code of a command may be ignored (meaning they are always considered successful) by prefixing the command with a dash (-) - this is similar to how make recipe lines work. The outcome of the environment is considered successful only if all commands (these + setup + teardown) succeeded (exit code ignored via the - or success exit code value of zero).
Note
The virtual environment binary path (see env_bin_dir) is prepended to the PATH environment variable, meaning commands will first try to resolve to an executable from within the virtual environment, and only after that outside of it. Therefore python translates as the virtual environments python (having the same runtime version as the base_python), and pip translates as the virtual environments pip.
Note
Inline scripts can be used, however note these are discovered from the project root directory, and is not influenced by change_dir (this only affects the runtime current working directory). To make this behaviour explicit we recommend that you make inline scripts absolute paths by prepending {tox_root}, instead of path/to/my_script prefer {tox_root}{/}path{/}to{/}my_script. If your inline script is platform dependent refer to platform-specification on how to select different script per platform.
Commands to run after running the commands. Execute regardless of the outcome of both commands and commands_pre. All evaluation and configuration logic applies from commands.
Change to this working directory when executing the test command. If the directory does not exist yet, it will be created (required for Windows to be able to execute any command).
Treat positional arguments passed to tox as file system paths and - if they exist on the filesystem and are in relative format - rewrite them according to the current and change_dir working directory. This handles automatically transforming relative paths specified on the CLI to relative paths respective of the commands executing directory.
When executing the commands keep going even if a sub-command exits with non-zero exit code. The overall status will be "commands failed", i.e. tox will exit non-zero in case any command failed. It may be helpful to note that this setting is analogous to the -k or --keep-going option of GNU Make.
If set to true a failing result of this test environment will not make tox fail (instead just warn).
Skip installation of the package. This can be used when you need the virtualenv management but do not want to install the current package into that environment.
Name of the virtual environment used to create a source distribution from the source tree for this environment.
tox package type used to package.
Indicates where the packaging root file exists (historically setup.py file or pyproject.toml now).
Name or path to a Python interpreter which will be used for creating the virtual environment, first one found wins. This determines in practice the Python for what we'll create a virtual isolated environment. Use this to specify the Python version for a tox environment. If not specified, the virtual environments factors (e.g. name part) will be used to automatically set one. For example, py310 means python3.10, py3 means python3 and py means python. If the name does not match this pattern the same Python version tox is installed into will be used.
3.1
After resolving this value if the interpreter reports back a different version number than implied from the name a warning will be printed by default. However, if
ignore_basepython_conflictis set, the value is ignored and we force thebase_pythonimplied from the factor name.Note
Leaving this unset will cause an error if the package under test has a different Python requires than tox itself and tox is installed into a Python that's not supported by the package. For example, if your package requires Python 3.10 or later, and you install tox in Python 3.9, when you run a tox environment that has left this unspecified tox will use Python 3.9 to build and install your package which will fail given it requires 3.10.
The Python environments site package - where packages are installed (the purelib folder path).
The binary folder where console/gui scripts are generated during installation.
The Python executable from within the tox environment.
Name of the Python dependencies. Installed into the environment prior to project after environment creation, but before package installation. All installer commands are executed using the tox_root as the current working directory. Each value must be one of:
- a Python dependency as specified by
440, - a requirement file when the value starts with
-r(followed by a file path), - a constraint file when the value starts with
-c(followed by a file path).
For example:
[testenv] deps = pytest>=7,<8 -r requirements.txt -c constraints.txt
Install the current package in development mode with develop mode. For pip this uses -e option, so should be avoided if you've specified a custom install_command that does not support -e.
When option can be one of wheel, sdist, editable, editable-legacy, skip, or external. If use_develop is set this becomes a constant of editable. If skip_install is set this becomes a constant of skip.
If wheel_build_env is set to wheel this will be the tox Python environment in which the wheel will be built. The value is generated to be unique per Python flavor and version, and prefixed with package_env value. This is to ensure the target interpreter and the generated wheel will be compatible. If you have a wheel that can be reused across multiple Python versions set this value to the same across them (to avoid building a new wheel for each one of them).
A list of "extras" from the package to be installed. For example, extras = testing is equivalent to [testing] in a pip install command.
tox supports operating with externally built packages. External packages might be provided in two wayas:
- explicitly via the
--installpkg <tox-run---installpkg>CLI argument, - setting the
packagetoexternaland using a tox packaging environment named<package_env>_external(seepackage_env) to build the package. The tox packaging environment takes all configuration flags of apython environment <python-options>, plus the following:
Name of the Python dependencies as specified by 440. Installed into the environment prior running the build commands. All installer commands are executed using the tox_root as the current working directory.
Commands to run that will build the package. If any command fails the packaging operation is considered failed and will fail all environments using that package.
When executing the commands keep going even if a sub-command exits with non-zero exit code. The overall status will be "commands failed", i.e. tox will exit non-zero in case any command failed. It may be helpful to note that this setting is analogous to the -k or --keep-going option of GNU Make.
Change to this working directory when executing the package build command. If the directory does not exist yet, it will be created (required for Windows to be able to execute any command).
A glob that should match the wheel/sdist file to install. If no file or multiple files is matched the packaging operation is considered failed and will raise an error.
Create virtual environments that also have access to globally installed packages. Note the default value may be overwritten by the VIRTUALENV_SYSTEM_SITE_PACKAGES environment variable.
Warning
In cases where a command line tool is also installed globally you have to make sure that you use the tool installed in the virtualenv by using python -m <command line tool> (if supported by the tool) or {env_bin_dir}/<command line tool>. If you forget to do that you will get an error.
Force virtualenv to always copy rather than symlink. Note the default value may be overwritten by the VIRTUALENV_COPIES or VIRTUALENV_ALWAYS_COPY (in that order) environment variables. This is useful for situations where hardlinks don't work (e.g. running in VMS with Windows guests).
True if you want virtualenv to upgrade pip/wheel/setuptools to the latest version. Note the default value may be overwritten by the VIRTUALENV_DOWNLOAD environment variable. If (and only if) you want to choose a specific version (not necessarily the latest) then you can add VIRTUALENV_PIP=20.3.3 (and similar) to your set_env.
Directory where to put the project metadata files.
Directory where to put project packages.
Determines the command used for installing packages into the virtual environment; both the package under test and its dependencies (defined with deps). Must contain the substitution key {packages} which will be replaced by the package(s) to install. You should also accept {opts} -- it will contain index server options such as --pre (configured as pip_pre).
Note
You can also provide arbitrary commands to the install_command. Please take care that these commands can be executed on the supported operating systems. When executing shell scripts we recommend to not specify the script directly but instead pass it to the appropriate shell as argument (e.g. prefer bash script.sh over script.sh).
The list_dependencies_command setting is used for listing the packages installed into the virtual environment.
If true, adds --pre to the opts passed to install_command. This will cause it to install the latest available pre-release of any dependencies without a specified version. If false, pip will only install final releases of unpinned dependencies.
tox allows creation of user level config-file to modify default values of the CLI commands. It is located in the OS-specific user config directory under tox/config.ini path, see tox --help output for exact location. It can be changed via TOX_CONFIG_FILE environment variable. Example configuration:
[tox]
skip_missing_interpreters = true