This release is a pre-release and may not be stable for production use.
pytest-telescope
Declared inputs. Isolated tests. Focused reruns.
Put input declarations beside pytest cases. A case with a declaration runs in a Linux Bubblewrap sandbox that shows it only its declared project files, and has its own reusable successful result. Two cases in the same file can declare different resources and rerun independently. Every other case runs as ordinary pytest.
import pytest
@pytest.mark.telescope(inputs=["data/red.json"], bundles=["pricing"])
def test_red(): ...
@pytest.mark.telescope(inputs=["data/blue.json"], bundles=["pricing"])
def test_blue(): ...
def test_note(): ... # ordinary: runs every time, no sandbox, no cache
Undeclared cases stay ordinary. A case without a literal inputs, bundles or
distributions field runs in an ordinary pytest session on every invocation. A declared
case is scoped: it sees its declared project files, the installed Python environment
and the system directories, all read-only, plus private scratch. Undeclared project
files do not exist in its view. Declarations at module, class, function, and parameter
levels add together with project defaults. cache=False alone leaves a case ordinary.
Try it
Requirements: Linux, Python 3.11+, and bwrap from Bubblewrap on a host that lets it
create user namespaces. There is no runtime image to build.
python -m venv .venv
. .venv/bin/activate
python -m pip install pytest-telescope==0.1.0a4
Follow the complete runnable quickstart for copyable application code, tests, JSON, and TOML. The base files are also in examples/quickstart.
From your configured project root:
python -m pytest_telescope plan
python -m pytest_telescope run --explain -- -q
python -m pytest_telescope run --explain -- -q
plan previews static routes and scopes. run runs ordinary cases in one ordinary
pytest session per suite and each scoped miss in its own sandbox. The second run executes
the ordinary cases again and reuses unchanged scoped successes. Summaries distinguish
routes, collection, fresh execution, cached results, failures, and unselected cases. New
files or parametrized cases cannot hide behind an old result.
Know the boundary
The sandbox controls the filesystem view only. It sets no CPU, memory, process or scratch limits and reports no CPU usage: limit and measure resources in the job that runs pytest. Scoped tests share the host network, so do not declare network-dependent tests as scoped. Scoped results are keyed by their declared files, the interpreter and the installed distributions; installing or upgrading a package reruns them.
The default case mode creates a fresh sandbox and pytest session for every scoped case.
Optional batch mode shares
ordinary pytest fixture lifetimes only among selected scoped cases with exactly equal
scopes in one suite/module. run --workers N runs up to N independent sandboxes at once.
If Bubblewrap is missing or cannot create namespaces, a run with scoped cases refuses
before any test runs; it never falls back to ordinary execution.
Filesystem isolation does not establish universal determinism. Make clock, randomness,
and native/external-state assumptions reproducible. Use run --force to execute again or
run --no-cache to bypass reuse and recording.
The dedicated CLI starts no host pytest session before its own sessions. pytest --telescope also routes to the controller, but other plugins may execute during host
pytest startup. pytest --telescope-plan is a static planning adapter. Ordinary pytest
stays ordinary when telescope mode is disabled; -p no:telescope disables plugin loading
entirely.
Version note: 0.1.0a4 replaces the Docker backend of 0.1.0a1 to 0.1.0a3 with ordinary
pytest plus Bubblewrap filesystem views; the runtime command, resource budgets and
runtime profiles are gone. The marker interface introduced in 0.1.0a2 remains supported.
Immutable 0.1.0a1 used file/group targets; central targets declarations must migrate to
markers, defaults, and bundles.
See the execution contract, API reference, marker/project reference, development guide, and publishing guide. Licensed under the MIT License.
Metadata
Release files for pytest-telescope 0.1.0a4
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| pytest_telescope-0.1.0a4.tar.gz | 148.9 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| pytest_telescope-0.1.0a4-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 204.4 kB
Release files / pytest_telescope-0.1.0a4.tar.gz
| Download URL | pytest_telescope-0.1.0a4.tar.gz |
|---|---|
| Size | 148.9 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
3ca8e6437a0e8434a856131a42c78baacdccefccae15f2075e54fe4ec0dbee25
|
|
BLAKE2b-256 checksum How to use checksums |
68cd361e574cbb3de5461d8ce8567a42ea76a9786c1ed71923b78d9424fa4a8a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Release files / pytest_telescope-0.1.0a4-py3-none-any.whl
| Download URL | pytest_telescope-0.1.0a4-py3-none-any.whl |
|---|---|
| Size | 55.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
13051c6d6a73db8816ba4bd3faff0fd031bcd4e40e21b87510e91fc7dd23c2cb
|
|
BLAKE2b-256 checksum How to use checksums |
2b450d5206a0cb4a02678d53c451d4c9b07d9ea7b5fc43cedfe7988a275877de
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Security for pytest-telescope 0.1.0a4
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.