ataraxis-automation 3.0.4

Description:

ataraxisautomation 3.0.4

ataraxis-automation
A Python library that provides scripts that support tox-based development automation pipelines used by other
Sun Lab projects.









Detailed Description
This library is one of the two 'base' dependency libraries used by every other Sun Lab project (the other being
ataraxis-base-utilities). It exposes a command-line interface
(automation-cli) that can be used through the tox-based project
development automation suite that comes with every Sun Lab project (we use tox as an analog to build system).
The commands from this library generally fulfill two major roles. First, they are used to set up, support,
or clean up after third-party packages (ruff, mypy, stubgen, grayskull, etc.) used by our tox tasks. Second, they
automate most operations with conda environments, such as creating / removing the environment and
installing / uninstalling the project from the environment.
The library can be used as a standalone module, but it is primarily designed to integrate with other Sun Lab projects,
providing development automation functionality. Therefore, it may require either adopting and modifying a
tox automation suite from one of the lab projects or significant refactoring to work with non-lab projects.

Features

Supports Windows, Linux, and OSx.
Optimized for runtime speed by preferentially using mamba and uv over conda and pip.
Compliments the extensive suite of tox-automation tasks used by all Sun Lab projects.
Pure-python API.
GPL 3 License.


Table of Contents

Dependencies
Installation
Usage
API Documentation
Developers
Versioning
Authors
License
Acknowledgements


Dependencies
For users, all library dependencies are installed automatically for all supported installation methods
(see Installation section). For developers, see the Developers section for
information on installing additional development dependencies.

Installation
Source

Download this repository to your local machine using your preferred method, such as git-cloning. Optionally, use one
of the stable releases that include precompiled binary wheels in addition to source code.
cd to the root directory of the project using your command line interface of choice.
Run python -m pip install . to install the project. Alternatively, if using a distribution with precompiled
binaries, use python -m pip install WHEEL_PATH, replacing 'WHEEL_PATH' with the path to the wheel file.

PIP
Use the following command to install the library using PIP: pip install ataraxis-automation
Conda / Mamba
Note. Due to conda-forge contributing process being more nuanced than pip uploads, conda versions may lag behind
pip and source code distributions.
Use the following command to install the library using Conda or Mamba: conda install ataraxis-automation

Usage
Quickstart
The easiest way to get Sun Lab automation to work for your project is to initialize the project using one of our
templates for
pure-python or
c-extension projects. To initialize and customize one of our
templates, follow these steps:

Navigate to the desired template via one of the links above and click Use this template button in the
top right corner of the page.
Initialize your project as necessary and download and unpack it on your local machine. To do this, you can use tools
such as git-cloning.
cd into the root directory of the project.
Use the tox -e adopt command to 'adopt' the project. The adoption process replaces placeholder markers in the
template 'meta' files with information appropriate for your project.
Add your source code and support files as needed.

Automation Command-Line Interface
All library functions designed to be called by end-users are exposed through the 'automation-cli' script.
This cli script is automatically exposed after installing the library into a conda or virtual environment.
Automation-CLI
While the preferred use case for this library is via 'tox' tasks, you can access all functions supplied by the library
by calling automation-cli from the shell that has access to the python environment with the library. Here are
some examples of how you can use the automation-cli directly:

Use automation-cli --help to verify that the cli is available and to see the list of supported commands.
Use automation-cli COMMAND-NAME --help to display additional information about a specific command. For example:
automation-cli import-env --help.

Tox automation
This library is intended to be used to augment 'tox' runtimes, and this is always the preferred use case.
To use any of the commands as part of a tox 'task,' add it to the 'commands' section of the tox.ini:
[testenv:create]
basepython = py310
deps =
ataraxis-automation>=3,<4
description =
Creates a minimally-configured conda environment using the requested python version and installs conda- and pip-
dependencies extracted from pyproject.toml file into the environment. Does not install the project!
commands =
automation-cli --verbose create-env --environment-name axa_dev --python-version 3.12

Logging and Printing
All cli commands come with two parameters exposed through the main cli group:

--verbose: Determines whether to display Information, Warning and Success messages to inform the user about
the ongoing runtime.
--log: Determines whether to save messages and errors to log files (located in automatically generated folder
inside user log directory).

Command-specific flags
Note! Many sub-commands of the cli have additional flags and arguments that can be used to further customize
their runtime. Consult the API documentation to see these options with detailed descriptions.
Warning! When using any cli command that uses --python-version flag from tox, you have to include
basepython= line in the environment configuration and set it to a python version different from the
one provided after --python-version argument. See the 'testenv:create' example above.
Intended cli use pattern
All cli commands are intended to be used through tox pipelines. The most recent version of Sun Lab tox configuration
is always available from this libraries' tox.ini file. Since this library plays a large role in our tox
automation pipelines, its tox configuration is always the most up to date and feature-packed compared to all other
Sun Lab projects.
Any well-maintained Sun Lab project comes with an up-to-date tox configuration that automates most 'meta'
development steps, such as code formatting, project testing, and project distribution. By automating most of these
steps, we seek to provide clear standards to be shared by internal and external collaborators. Additionally, this
allows developers to focus on the important task of planning and writing the code of their projects over 'meta' tasks
like code formatting.
Available 'tox' commands
This library is tightly linked to our 'tox' configuration. Most of our 'tox' tasks either use some functions from this
library in addition to external packages or entirely consist of calling functions from this library. Therefore, this
documentation would not have been complete without having a section about our 'tox' tasks, in addition to the basic
information about our 'automation-cli' script.
Note that commands listed here may and frequently are modified based on the specific needs of each project that
uses them. Therefore, this section is not a replacement for studying the tox.ini file for the specific project you
seek to develop. Additionally, using tasks listed here 'as is' may not work for your project without customizations.
Most of the commands in this section are designed to be executed together (some sequentially, some in-parallel) when
a general tox command is used. These are considered 'checkout' tasks, and they generally cover the things that
need to be present for a commit to be pushed to the main branch of any Sun Lab project.
Lint
Shell command: tox -e lint
Uses ruff and mypy to statically analyze and,
where possible, fix code formatting, typing, and problematic use patterns. This helps to ensure the code is
formatted according to our standards and does not contain easily identifiable problematic use patterns, such as
type violations. As part of its runtime, this task uses automation cli to remove existing stub (.pyi) files from
the source folders, as they interfere with type-checking.
Example tox.ini section:
[testenv: lint]
description =
Runs static code formatting, style and typing checkers. Mypy may not work properly until py.typed marker is
added by 'stubs' task.
deps =
mypy>=1,<2
ruff>=0,<1
types-pyyaml>=6,<7
ataraxis-automation>=3,<4
depends = uninstall
# Note! Basepython has to be set to the 'lowest' version supported by your project
basepython = py310
commands =
automation-cli --verbose purge-stubs
ruff check --select I --fix
ruff format
mypy . --strict --extra-checks --warn-redundant-cast

Stubs
Shell command: tox -e stubs
Uses stubgen to generate stub (.pyi) files and,
via automation-cli, distribute them to the appropriate levels of the library source folder. This is necessary to
support static type-checking for projects that use your project. As part of that process, automation-cli also ensures
that there is a 'py.typed' marker file in the highest library directory. This is required for type-checkers like mypy
to recognize the project as 'typed' and process it during type-checking tasks.
Example tox.ini section:
[testenv: stubs]
description =
Generates the py.typed marker and the stub files using the built library wheel. Formats the stubs with ruff before
moving them to appropriate source sub-directories.
deps =
mypy>=1,<2
ruff>=0,<1
ataraxis-automation>=3,<4
depends = lint
commands =
automation-cli --verbose process-typed-markers
stubgen -o stubs --include-private --include-docstrings -p ataraxis_automation -v
ruff check --select I --fix
ruff format
automation-cli --verbose process-stubs

Test
Shell command: tox -e pyXXX-test
This task is available for all python versions supported by each project. For example, automation supports versions
3.10, 3.11, and 3.12. Therefore, it will have tox -e py310-test, tox -e py311-test and
tox -e py312-test as valid 'test' tasks. These tasks are used to build the project in an isolated environment and
run the tests expected to be located inside the project_root/tests directory to verify the project works as expected
for each python version. This is especially relevant for c-extension projects that compile code for specific python
versions and platforms.
Example tox.ini section:
[testenv: {py310, py311, py312}-test]
package = wheel
description =
Runs unit and integration tests for each of the python versions listed in the task name. Uses 'loadgroup' balancing
and all logical cores to optimize runtime speed while allowing manual control over which cores execute tasks (see
pytest-xdist documentation).
deps =
pytest>=8,<9
pytest-cov>=5,<6
pytest-xdist>=3,<4
coverage[toml]>=7,<8
depends = uninstall
setenv =
# Sets environment parameters, which includes intermediate coverage aggregation file used by coverage.
COVERAGE_FILE = reports{/}.coverage.{envname}
commands =
# Make sure the --cov is always set to the intended library name, so that coverage runs on the whole library
# exactly once.
pytest --import-mode=append --cov=ataraxis_automation --cov-config=pyproject.toml --cov-report=xml \
--junitxml=reports/pytest.xml.{envname} -n logical --dist loadgroup

Coverage
Shell command: tox -e coverage
This task is designed to be used in-conjunction with the 'test' task. It aggregates code coverage data for different
python versions and compiles it into a html-report accessible by opening project_root/reports/coverage_html/index.html
in a browser. For all lab projects, we try to provide as close to 100% code coverage as possible for each project.
Example tox.ini section:
[testenv:coverage]
skip_install = true
description =
Combines test-coverage data from multiple test runs (for different python versions) into a single html file. The
file can be viewed by loading the 'reports/coverage_html/index.html'.
setenv = COVERAGE_FILE = reports/.coverage
depends = {py310, py311, py312}-test
deps =
junitparser>=3,<4
coverage[toml]>=7,<8
commands =
junitparser merge --glob reports/pytest.xml.* reports/pytest.xml
coverage combine --keep
coverage xml
coverage html

Doxygen
Shell command: tox -e doxygen
Note! This task is only used in c-extension projects.
This task is unique to our c-extension projects (projects that contain compiled c / c++ code). It uses
Doxygen to parse doxygen-styled docstrings used in our c-code to make them accessible to
Sphinx (used as part of our 'docs' task). This allows automatically building
C/C++ API documentation and organically bundling it with Python API documentation via sphinx.
Example tox.ini section:
[testenv:doxygen]
skip_install = true
description =
Generates C++ / C source code documentation using Doxygen. This assumes the source code uses doxygen-compatible
docstrings and that the root directory contains a Doxyfile that minimally configures Doxygen runtime.
allowlist_externals = doxygen
depends = uninstall
commands =
doxygen Doxyfile

Docs
Shell command: tox -e docs
Uses sphinx to automatically parse docstrings from source code and use them
to build API documentation for the project. C-extension projects use a slightly modified version of this task that uses
breathe to convert doxygen-generated xml files for c-code into a format
that sphinx can parse. This way, c-extension projects can include both Python and C/C++ API documentation as part of
the same file. This task relies on the configuration files stored inside /project_root/docs/source folder to define
the generated documentation format. Built documentation can be viewed by opening
project_root/docs/build/html/index.html in a browser.
Example tox.ini section for a pure-python project:
[testenv:docs]
description =
Builds the API documentation from source code docstrings using Sphinx. The result can be viewed by loading
'docs/build/html/index.html'.
depends = uninstall
deps =
sphinx>=7,<8
importlib_metadata>=8,<9
sphinx-rtd-theme>=2,<3
sphinx-click>=6,<7
sphinx-autodoc-typehints>=2,<3
commands =
sphinx-build -b html -d docs/build/doctrees docs/source docs/build/html -j auto -v

Example tox.ini section for a c-extension project:
[testenv:docs]
description =
Builds the API documentation from source code docstrings using Sphinx. Integrates with C / C++ documentation via
Breathe, provided that Doxygen was used to generate the initial .xml file for C-extension sources. The result can
be viewed by loading 'docs/build/html/index.html'.
depends = doxygen
deps =
sphinx>=7,<8
importlib_metadata>=8,<9
sphinx-rtd-theme>=2,<3
sphinx-click>=6,<7
sphinx-autodoc-typehints>=2,<3
breathe>=4,<5
commands =
sphinx-build -b html -d docs/build/doctrees docs/source docs/build/html -j auto -v

Build
Shell command: tox -e build
This task differs for c-extension and pure-python projects. In both cases, it builds a source-code distribution (sdist)
and a binary distribution (wheel) for the project. These distributions can then be uploaded to GitHub, PyPI, and Conda
for further distribution or shared with other people manually. Pure Python projects use
hatchling and build to generate
one source-code and one binary distribution. C-extension projects use
cibuildwheel to compile c-code for all supported platforms and
architectures, building many binary distribution files alongside source-code distribution generated via build.
Example tox.ini section for a pure-python project:
[testenv:build]
skip-install = true
description =
Builds the source code distribution (sdist) and the binary distribution package (wheel). Use 'upload' task to
subsequently upload built wheels to PIP.
deps =
build>=1,<2
hatchling>=1,<2
allowlist_externals =
docker
commands =
python -m build . --sdist
python -m build . --wheel

Example tox.ini section for a c-extension project:
[testenv:build]
skip-install = true
description =
Builds the source code distribution (sdist) and compiles and assembles binary wheels for all architectures of the
host-platform supported by the library. Use 'upload' task to subsequently upload built wheels to PIP.
deps =
cibuildwheel[uv]>=2,<3
build>=1,<2
allowlist_externals =
docker
commands =
python -m build . --sdist
cibuildwheel --output-dir dist --platform auto

Upload
Shell command: tox -e upload
Uploads the sdist and wheel files created by 'build' task to PyPI. When this task runs for the
first time, it uses automation-cli to generate a .pypirc file and store user-provided PyPI upload token into that file.
This allows reusing the token for later uploads, streamlining the process. The task is configured to skip uploading
already uploaded files to avoid errors. This is all it takes to make your project available for downloads using
'pip install.'
Example tox.ini section:
[testenv:upload]
description =
Uses twine to upload all files inside the '/dist' folder to pip, ignoring any files that are already uploaded.
Uses API token stored in '.pypirc' file or provided by user to authenticate the upload.
deps =
twine>=5,<6
ataraxis-automation>=3,<4
allowlist_externals =
distutils
commands =
automation-cli --verbose acquire-pypi-token {posargs:}
twine upload dist/* --skip-existing --config-file .pypirc

Recipe
Shell command: tox -e recipe
This task is the first out of multiple steps to upload a project to conda-forge channel.
Overall, this process leads to your project becoming installable with 'conda install.' The task uses automation-cli
to generate a 'recipe' folder inside the root project directory and then uses grayskull to generate the project recipe
using the most recent pip version of the project. This task assumes that pip contains the source-code distribution
(sdist) for the project. Since all our projects are distributed under GPL3 license, they always contain source-code
distributions. See conda-forge documentation for more
information on uploading packages to conda-forge.
Example tox.ini section:
[testenv:recipe]
skip_install = true
description =
Uses grayskull to parse the source code tarball stored on pip and generate the recipe used to submit the
package to conda-forge. The submission process has to be carried out manually, see
https://conda-forge.org/docs/maintainer/adding_pkgs/ for more details.
deps =
grayskull>=2,<3
ataraxis-automation>=3,<4
commands =
automation-cli --verbose generate-recipe-folder
grayskull pypi ataraxis_automation -o recipe --strict-conda-forge --list-missing-deps -m Inkaros

Conda-environment manipulation tox commands
Note! These commands were written to automate repetitive tasks associated with project-specific conda
environments. They assume that there is a validly configured conda or mamba version installed and accessible from the
shell of the machine these commands are called on. All of these tasks can be replaced with sequences of manual conda
or pip commands if necessary.
Install
Shell command: tox -e install
Installs the project into the requested environment. This task is used to build and install the project into the
project development environment. This is a prerequisite for manually running and testing projects that are being
actively developed. During general 'tox' runtime, this task is used to (re)install the project into the
project environment as necessary to avoid collisions with 'tox.'
Note! The 'basepython' argument should always be set to a version different from '--python-version.'
Example tox.ini section:
[testenv:install]
basepython = py310
deps =
ataraxis-automation>=3,<4
depends =
uninstall
lint
stubs
{py310, py311, py312}-test
coverage
docs
description =
Builds and installs the project into the specified conda environment. If the environment does not exist, creates
it before installing the project.
commands =
automation-cli --verbose install-project --environment-name axa_dev --python-version 3.12

Uninstall
Shell command: tox -e uninstall
Removes the project from the requested environment. This task is used in-conjunction with the 'install' task to
avoid version collisions when running general 'tox' tasks.
Note! The 'basepython' argument should always be set to a version different from '--python-version.'
Example tox.ini section:
[testenv:uninstall]
basepython = py310
deps =
ataraxis-automation>=3,<4
description =
Uninstalls the project from the specified conda environment. If the environment does not exist
this task silently succeeds.
commands =
automation-cli --verbose uninstall-project --environment-name axa_dev --python-version 3.12

Create
Shell command: tox -e create
Creates the requested conda environment and installs project dependencies listed in pyproject.toml into the environment.
This task is intended to be used when setting up project development environments for new platforms and architectures.
To work as intended, it uses automation-cli to parse the contents of tox.ini and pyproject.toml files to generate a
list of project dependencies. It assumes that dependencies are stored using Sun Lab format: inside 'conda,' 'noconda,'
'condarun,' and general 'dependencies' section.
Note! The 'basepython' argument should always be set to a version different from '--python-version.'
Example tox.ini section:
[testenv:create]
basepython = py310
deps =
ataraxis-automation>=3,<4
description =
Creates a minimally-configured conda environment using the requested python version and installs conda- and pip-
dependencies extracted from pyproject.toml file into the environment. Does not install the project!
commands =
automation-cli --verbose create-env --environment-name axa_dev --python-version 3.12

Remove
Shell command: tox -e remove
Removes the project-specific conda environment. Primarily, this task is intended to be used to clean the local system
after finishing development and to hard-reset the environment (this use is discouraged!).
Example tox.ini section:
[testenv:remove]
basepython = py310
deps =
ataraxis-automation>=3,<4
description =
Removes the requested conda environment, if it is installed locally.
commands =
automation-cli --verbose remove-env --environment-name axa_dev

Provision
Shell command: tox -e provsion
This task is a 'soft' combination of the 'remove' and 'create' tasks that allows resetting environments without deleting
them. It first uninstalls all packages in the environment and then re-installs project dependencies using pyproject.toml
file. This is the same procedure as used by the 'create' task. Since this task does not remove the environment, it
preserves all references used by tools such as IDEs, but completely resets all packages in the environment. This can
be used to both reset and actualize project development environments to match the latest version of the
.toml specification.
Note! The 'basepython' argument should always be set to a version different from '--python-version.'
Example tox.ini section:
[testenv:provision]
basepython = py310
deps =
ataraxis-automation>=3,<4
description =
Provisions an already existing environment by uninstalling all packages from the environment and then installing the
project dependencies using pyproject.toml specifications.
commands =
automation-cli --verbose provision-env --environment-name axa_dev --python-version 3.12

Export
Shell command: tox -e export
Exports the target development environment as a .yml and spec.txt files. This task is used before distributing new
versions of the project. This allows end-users to generate an identical copy of the development environment, which is
a highly encouraged feature for most projects. While our 'create' and 'provision' tasks make this largely obsolete, we
still include exported environments in all our project distributions.
Example tox.ini section:
[testenv:export]
deps =
ataraxis-automation>=3,<4
description =
Exports the requested conda environment to the 'envs' folder as a .yml file and as a spec.txt with revision history.
commands =
automation-cli --verbose export-env --environment-name axa_dev

Import
Shell command: tox -e import
Imports the project development environment from an available '.yml' file. If the environment does not exist, this
creates an identical copy of the environment stored in the .yml file. If the environment already exists, it is instead
updated using the '.yml' file. The update process is configured to prune any 'unused' packages not found inside the
'.yml' file. This can be used to clone or actualize the project development environment from a file distributed via
'export' task.
Example tox.ini section:
[testenv:import]
deps =
ataraxis-automation>=3,<4
description =
Discovers and imports (installs) a new or updates an already existing environment using the .yml file
stored in the 'envs' directory.
commands =
automation-cli --verbose import-env --environment-name axa_dev

Rename
Shell command: tox -e rename
Renames all environment files inside the project_root/envs directory to use the provided base_name (obtained from
user via dialog). This is used to quickly rename all environment files, which is helpful when renaming the project.
Primarily, this task is used during 'adoption' task, but it also has uses during general development. The renaming
procedure also changes the value of the 'name' field inside the '.yml' files. Environments created from renamed files
will use the 'altered' environment name.
Example tox.ini section:
[testenv:rename]
deps =
ataraxis-automation>=3,<4
description =
Replaces the base environment name used by all files inside the 'envs' directory with the user-input name.
commands =
automation-cli --verbose rename-environments

Adopt
Shell command: tox -e adopt
This task is designed to be used on new projects initialized from one of Sun Lab templates. Templates come with
'placeholders' in most meta-files (pyproject.toml, tox.ini, etc.). This task finds and replaces the placeholders with
user-defined values (obtained via dialog). This simplifies customizing the template projects to suite the specific needs
of your particular project, while still benefiting from the Sun Lab structure and support files.
Example tox.ini section:
[testenv:adopt]
deps =
ataraxis-automation>=3,<4
description =
Adopts a Sun Lab template-generated project by replacing default placeholders with user-provided information.
commands =
automation-cli --verbose adopt-project


API Documentation
See the API documentation for the
detailed description of the methods and classes exposed by components of this library. Note the documentation
also includes a list of all command-line interface functions provided by automation-cli script.

Developers
This section provides installation, dependency, and build-system instructions for the developers that want to
modify the source code of this library. Additionally, it contains instructions for recreating the conda environments
that were used during development from the included .yml files.
Installing the library

Download this repository to your local machine using your preferred method, such as git-cloning.
cd to the root directory of the project using your command line interface of choice.
Install development dependencies. You have multiple options of satisfying this requirement:

Preferred Method: Use conda or pip to install
tox or use an environment that has it installed and
call tox -e import to automatically import the os-specific development environment included with the
source code in your local conda distribution. Alternatively, you can use tox -e create to create the
environment from scratch and automatically install the necessary dependencies using pyproject.toml file. See
environments section for other environment installation methods.
Run python -m pip install .'[dev]' command to install development dependencies and the library using
pip. On some systems, you may need to use a slightly modified version of this command:
python -m pip install .[dev].
As long as you have an environment with tox installed
and do not intend to run any code outside the predefined project automation pipelines, tox will automatically
install all required dependencies for each task.



Note: When using tox automation, having a local version of the library may interfere with tox tasks that attempt
to build the library using an isolated environment. While the problem is rare, our 'tox' pipelines automatically
install and uninstall the project from its' conda environment. This relies on a static tox configuration and will only
target the project-specific environment, so it is advised to always tox -e import or tox -e create the
project environment using 'tox' before running other tox commands.
Additional Dependencies
In addition to installing the required python packages, separately install the following dependencies:

Python distributions, one for each version that you intend to support.
Currently, this library supports version 3.10 and above. The easiest way to get tox to work as intended is to have
separate python distributions, but using pyenv is a good alternative too.
This is needed for the 'test' task to work as intended.

Development Automation
This project comes with a fully configured set of automation pipelines implemented using
tox. Check tox.ini file for details about
available pipelines and their implementation. Alternatively, call tox list from the root directory of the project
to see the list of available tasks. Note, automation pipelines for this library list itself as a circular
dependency in some use cases. Generally, this is not an issue when patching or adding new functionality, but requires
extra care when working on major library versions.
Note! All commits to this library have to successfully complete the tox task before being pushed to GitHub.
To minimize the runtime task for this task, use tox --parallel.
Environments
All environments used during development are exported as .yml files and as spec.txt files to the envs folder.
The environment snapshots were taken on each of the three explicitly supported OS families: Windows 11, OSx (M1) 14.5
and Linux Ubuntu 22.04 LTS.
Note! Since the OSx environment was built on an M1 (Apple Silicon) platform, it may not work on Intel-based
Apple devices.
To install the development environment for your OS:

Download this repository to your local machine using your preferred method, such as git-cloning.
cd into the envs folder.
Use one of the installation methods below:

Preferred Method: Install tox or use another
environment with already installed tox and call tox -e import-env.
Alternative Method: Run conda env create -f ENVNAME.yml or mamba env create -f ENVNAME.yml.
Replace 'ENVNAME.yml' with the name of the environment you want to install (axa_dev_osx for OSx,
axa_dev_win for Windows, and axa_dev_lin for Linux).



Hint: while only the platforms mentioned above were explicitly evaluated, this project is likely to work on any
common OS, but may require additional configurations steps.
Since the release of ataraxis-automation 2.0.0, you can also create the development environment from scratch
via pyproject.toml dependencies. To do this, use tox -e create from project root directory.
Automation Troubleshooting
Many packages used in 'tox' automation pipelines (uv, mypy, ruff) and 'tox' itself are prone to various failures. In
most cases, this is related to their caching behavior. Despite a considerable effort to disable caching behavior known
to be problematic, in some cases it cannot or should not be eliminated. If you run into an unintelligible error with
any of the automation components, deleting the corresponding .cache (.tox, .ruff_cache, .mypy_cache, etc.) manually
or via a cli command is very likely to fix the issue.

Versioning
We use semantic versioning for this project. For the versions available, see the
tags on this repository.

Authors

Ivan Kondratyev (Inkaros)


License
This project is licensed under the GPL3 License: see the LICENSE file for details.

Acknowledgments

All Sun Lab members for providing the inspiration and comments during the
development of this library.
click project for providing the low-level command-line-interface functionality
for this project.
pyyaml, appdirs,
and tomli for providing low-level functionality for some of the automation
functions.
The teams behind pip, uv,
conda, mamba and tox,
which form the backbone of our code distribution and management pipeline.
The creators of all other projects listed in out pyproject.toml file and used in automation
pipelines across all Sun Lab projects.