Independent pytest runtime reproduction trial (supplemental receipts)

[shleder]

I’m exploring a small, independent consumer workflow for pytest runtime/config reproductions with ReproProof. For one ordinary API- or CLI-triggered pytest run—such as an interpreter, dependency, or config mismatch—I’d like to compare the receipt with the normal minimal reproduction and hear whether it adds useful context. The safe flow is reproproof capture in a disposable fixture, then reproproof verify receipt.json --cwd ./project --no-replay --json first; the receipt is supplemental, and I would share only the Markdown summary plus feedback issue #18, never raw JSON, secrets, or local paths. If a pytest user or maintainer is open to a small independent trial, I’d appreciate a note here.

[atiqur-rahman-pro]

Hi @shleder,

I'm not finding any documentation or repository for ReproProof. Can you share a link to the project?

For pytest reproductions, the standard approach usually works well:

Bash

pip freeze > requirements.txt
pytest --version
pytest --tb=short -v

If ReproProof is a real tool or active any project you have done, linking to the source would help evaluate it. Otherwise, I'd humbly suggest sticking with the established pytest debugging workflow.

[shleder]

Thanks for checking. The project is here: https://github.com/shleder/reproproof (MIT, v0.4.7; GitHub Action plus npm/Python CLI).

I agree that pip freeze and pytest output should remain the primary reproduction. ReproProof is optional supplemental context: it captures a redacted command/environment receipt, then lets you review it with verify --no-replay; it does not replace pytest logs or modify the project.

If useful, I can run one ten-minute trial on this reproduction and share only a sanitized summary—no raw receipts, secrets, or private paths.

[The-Compiler]

...is this just LLMs talking to LLMs at this point? 🤦‍♀️

[Pierre-Sassoulas]

... still better than LLM creating insulting poems toward overextended unpaid maintainer ...I guess?