Copyright 2025 Caleb Evans
Released under the MIT license

Multi-Line Replacer (mlr) is a CLI utility for replacing multi-line hunks of strings across one or more files. Matching is mostly textual, but wildcard matching is supported, and replacements are indentation-aware.

You can install MLR via the uv package manager:

# via uv
uv tool install multi-line-replacer

This tool requires Python 3.9 or newer.

The workflow takes one or more files on which to run replacements, and then one or more "replacement rule" files with the -r flag:

mlr .github/workflows/*.yml -r example-rules/uv-gha.md

Each replacement rule must be a Markdown file with one or more pairs of GFM fenced code blocks (see documentation). Every odd code block represents the target text to replace, and every even code block represents the textual replacement. All other Markdown formatting is ignored, so feel free to add headings, explainer text, or anything else!

This rule replaces flake8 with ruff in a Github Actions linting workflow.

## flake8

```yml
- name: Run flake8
  run: flake8 MATCH_UNTIL_END_OF_LINE
```

## ruff

```yml
- name: Run ruff
  run: |
    uv run ruff check .
    uv run ruff format --check .
```

There are two special wildcard variables:

• MATCH_UNTIL_END_OF_LINE (([^\n]*))
• MATCH_ALL_BETWEEN ((.*?), where . matches anything including newlines)

These variables can be used anywhere in any code block representing the target text to match. Word boundaries are not required around them (e.g. vMATCH_UNTIL_END_OF_LINE is allowed).

You can also access environment variable values anywhere in your target text or replacement text. To do so, simply specify the name of your environment variable prefixed with MATCH_ENV_ (e.g. if your environment variable is FOO_BAR, you would write MATCH_ENV_FOO_BAR into your rule file).

For instance, suppose you wish to upgrade the build system across a number of Python projects. If you define PROJECT_BUILD_SYSTEM, PROJECT_BUILD_BACKEND, and PROJECT_PKG_NAME, you could write a rule file to use them like so:

## setuptools build-system

```toml
[build-system]
requires = ["MATCH_ENV_PROJECT_BUILD_SYSTEM"]
build-backend = "MATCH_ENV_PROJECT_BUILD_BACKEND"
```

## uv_build build-system

```toml
[build-system]
requires = ["uv_build>=0.7.19,<0.8.0"]
build-backend = "uv_build"

[tool.uv.build-backend]
module-name = "MATCH_ENV_PROJECT_PKG_NAME"
module-root = ""
```

If you want to remove every line that's matched by your target text, simply use an empty fenced code block for the replacement block in your rule file.

## clone with submodules

```yml
with:
  submodules: recursive
```

## disable submodule detection

```yml
```

If you use the wildcard variables MATCH_UNTIL_END_OF_LINE or MATCH_ALL_BETWEEN in your target text, you can reference each captured value in your replacement text using MATCH_REF_1, MATCH_REF_2, etc. Backreferences are numbered in the (left‑to‑right) order the wildcard variables appear.

In the following example, we refactor a GitHub Actions step that currently exports three environment variables inline (hard for later steps to reuse) into an env block while also composing a friendly echo message. Each wildcard captures a semantically distinct value (project name, Python version, and cache key) and we then reuse them in multiple places.

## CI environment variables as code

```yml
run: |
  export PROJECT_NAME=MATCH_ALL_BETWEEN
  export PY_VERSION=MATCH_ALL_BETWEEN
  export CACHE_KEY=MATCH_ALL_BETWEEN
  echo "Using ${PROJECT_NAME} on Python ${PY_VERSION} (cache: ${CACHE_KEY})"
```

## CI environment variables as configuration

```yml
env:
  PROJECT_NAME: MATCH_REF_1
  PY_VERSION: MATCH_REF_2
  CACHE_KEY: MATCH_REF_3
run: |
  echo "Using ${PROJECT_NAME} on Python ${PY_VERSION} (cache: ${CACHE_KEY})"
```

You can perform a dry run of your replacements using the --dry-run flag. This will simulate all replacements and report the results without actually writing any changes to disk.

You can suppress all output (except for errors) using the --quiet or -q flag.

The tool supports Unix (LF) and Windows (CRLF) line endings. If a file contains mixed line endings, all line endings in the file are normalized to use whichever line ending appeared first in the file.

To better understand the expected rules format and what's allowed, please see the example-rules directory.

Multi-Line Replacer was built as my solution to an intermediate need I had while writing a large migration script. I had 17 Python projects using old tooling, and the script was written to migrate these projects to uv and ruff.

Part of this migration process necessitated performing textual replacements on multi-line hunks of code. Regular expressions and editors like VS Code could somewhat achieve this, although they required escaping special characters and carefully specifying indentation. In other words, those tools proved to be too rigid and inflexible.

Given these constraints, I conceived of a utility that could perform multi-line replacements with a friendlier authoring experience and greater indentation awareness. The implementation took several iterations to achieve positive results, but by the end, it contributed significantly to the successful migration of all 17 projects. From there, I decided to release it to the world as a more flexible and automated system for replacing multi-line hunks of code.