Today, pytest-markdown-docs only collects code fences tagged py, python, or python3.
Once a fence is collected, it runs with the default runner unless the fence explicitly selects a registered custom runner, e.g.
```python runner:MyCustomRunner
```
Because collection is gated on Python fence languages, non-Python fences are ignored before custom runner selection can happen. For example, even if MyCustomRunner is registered, this fence is not collected today:
```js runner:MyCustomRunner
```
Ideally, custom runners should be able to opt non-Python fences into collection in two ways:
- runner: should explicitly opt any fence language into collection with the named registered runner.
- register_runner(default_for=(...)) should allow a runner to become the default for one or more fence languages, so users do not have to repeat runner: on every fence.
@register_runner(default_for=("js", "javascript"))
class JavascriptRunner(DefaultRunner):
...
With this specific design,
- A fence with runner: uses that named runner.
- A fence whose language is listed in default_for uses that language-specific default runner.
- Built-in Python fences (py, python, python3) use the global default runner.
- Other fences are ignored.
Today, pytest-markdown-docs only collects code fences tagged
py,python, orpython3.Once a fence is collected, it runs with the default runner unless the fence explicitly selects a registered custom runner, e.g.
Because collection is gated on Python fence languages, non-Python fences are ignored before custom runner selection can happen. For example, even if
MyCustomRunneris registered, this fence is not collected today:Ideally, custom runners should be able to opt non-Python fences into collection in two ways:
With this specific design,