Tooling

Build, lint, and CI tools the repository depends on. These are everything that runs against your code automatically.

Python: ruff

Ruff is the only Python linter. Configuration is in pyproject.toml:

[tool.ruff]
target-version = "py39"

[tool.ruff.lint]
extend-select = ["B", "C", "I", "W"]
exclude = ["extensions", "extensions-disabled"]
ignore = [
    "E501",  # Line too long
    "E721",  # Do not compare types, use isinstance
    "E731",  # Do not assign a lambda expression, use a def
    "I001",  # Import block is un-sorted or un-formatted
    "C901",  # Function is too complex
    "C408",  # Rewrite as a literal
    "W605",  # invalid escape sequence
]

[tool.ruff.lint.per-file-ignores]
"webui.py" = ["E402"]

[tool.ruff.lint.flake8-bugbear]
extend-immutable-calls = ["fastapi.Depends", "fastapi.security.HTTPBasic"]

Run locally:

ruff check .              # check
ruff check --fix .        # apply autofixes

Notable choices:

• Line length is not enforced — long URLs and prompt examples in docstrings would otherwise dominate.
• Import sorting is disabled — historical reasons; ruff would reorder thousands of files. Don't fight it.
• Complexity is not enforced — the largest functions (process_images_inner, create_ui) are thousands of lines but considered acceptable.

JavaScript: eslint

ESLint config is in .eslintrc.js. The npm scripts in package.json:

"scripts": {
    "lint": "eslint .",
    "fix": "eslint --fix ."
}

npm install
npm run lint
npm run fix

Code style is browser-compatible ES6 (no transpiler, no bundler). The Gradio app loads files in javascript/ in alphabetical order at page load — this is why some files are named to control load order (localStorage.js is loaded before localization.js, etc.).

Spell-checking

The repo uses typos via a .typos.toml (named _typos.toml). It excludes a small list of intentional ML/Stable Diffusion jargon. Spelling fixes appear in commit history under "chore: fix typos" merges.

CI workflows

All CI lives in .github/workflows/:

Workflow	Trigger	What it does
run_tests.yaml	push / PR (same-repo only)	CPU server boot + pytest + coverage
on_pull_request.yaml	PR	ruff + eslint
warns_merge_master.yml	PR opened	Comments a warning if the PR targets master

The run_tests.yaml workflow caches models/ between runs (key ********** — yes, that's what's in the file) and uses actions/setup-python@v5 pinned to Python 3.10.6 to match the repo's recommended interpreter.

There is no CI for ROCm, MPS, or DirectML; those backends are only validated by user reports.

Boot/launcher tooling

The project's "build system" is essentially the launcher:

• launch.py → modules/launch_utils.py prepare_environment() handles dependency installation.
• webui.sh and webui.bat wrap the venv setup and pass control to launch.py.
• webui-user.sh / webui-user.bat are the user-edited entry points where COMMANDLINE_ARGS, python_cmd, venv_dir and TORCH_COMMAND are typically set.
• webui-macos-env.sh layers Apple Silicon-specific defaults on top.

webui.sh understands a small set of env vars: python_cmd, venv_dir, LAUNCH_SCRIPT, ERROR_REPORTING, KEEP_GOING. These are not flags — they're shell variables exported before the script runs.

Dependency pinning

Two requirements files coexist:

File	Used by	Purpose
requirements.txt	Read-only / informational	Lists dependencies without versions
requirements_versions.txt	prepare_environment()	Pinned versions actually installed
requirements_npu.txt	Ascend NPU users	Replaces torch with the NPU build
requirements-test.txt	CI / local test runs	pytest, pytest-base-url, requests

When bumping a dependency, edit requirements_versions.txt. CI will catch the mismatch on the next run.

What this project does not use

• No bundler (webpack, vite, esbuild). JavaScript is plain ES6 served by Gradio.
• No CSS preprocessor. There is one style.css.
• No type checker (mypy, pyright). Some modules use type hints; checking is not enforced.
• No pre-commit hooks shipped in-tree.
• No formatter. Ruff's format is not invoked; styling is informal.
• No Docker image is published from this repo (third-party Dockerfiles exist).
• No release automation; tags are cut by hand by AUTOMATIC1111.