Wing Pro 12.1 Autonomous Development Test: Reviving the pdfrw PDF Library

The Request

The run started from one prompt, entered as a task in Wing's Tasks tool:

I'd like to revive pdfrw, a pure-Python library for reading, writing and combining PDF files. Its last commit was in 2018 and its last release in 2017, but it still gets about 3 million downloads a month. This working copy is a clone of https://github.com/pmaupin/pdfrw with its full history. I want a maintained fork that works on current Python on macOS, Linux and Windows.

First find out where it stands: which Python versions it runs on, what its tests cover (measure it), and which of the open GitHub issues are real bugs you can reproduce. Then bring it up to date with modern packaging, the Python versions currently supported, and a test suite that runs anywhere with good coverage. Fix the bugs you can reproduce, each with a regression test, starting with any that silently lose pages or write broken files. Check its output with independent tools, not just by reading it back with pdfrw. Keep the public API compatible, so that existing users only have to change the package name they install. Note the upstream issue number in each fix and in a changelog.

Tests must create their own PDFs and run offline. Don't download or commit PDFs from issue reports, the web, or the old static_pdfs collection. Keep the original license file as it is, and credit Patrick Maupin and the other original authors in the README and the package metadata. The fork needs a new name on PyPI: suggest a few that are free, but don't publish anything, push, or post on the upstream project.

Once the tests run, set up one of the example scripts in Wing as the main entry point so I can test/debug it. Run all tasks to completion except small details and ideas for future improvements.

Commit a screenshot of each major visible change under docs/shots/ since we'll be creating a publishable trace of this run later.

Assessing pdfrw

The Tasks Manager ran the prompt as a research task first. Its agent cloned pdfrw into a scratch area and found that it ran on Python 2.7 through 3.14, with warnings on 3.12 and later, and that its tests that run offline covered only 28% of the code. It reproduced the worst of the open issues with PDFs its scripts built themselves: a page tree that one bad entry emptied, files whose later edits were ignored, encrypted files copied as blank pages, and errors partway through writing that left truncated files.

The prompt was wrong about one thing. The working copy held only Wing's project files, not a clone of pdfrw. The Tasks Manager noticed this before starting, and asked the user whether to bring in upstream's history. The user chose to import the code only, so the run started from upstream's last commit. Before publishing, upstream's full history was put back underneath, so the original authors' commits come first in the published repository.

The Revival

Once the user accepted the plan, the Manager filed its steps as tasks. The packaging and test harness came first, since everything else depended on them: pyproject.toml, support for Python 3.11 and later, a CI matrix for Linux, macOS and Windows, and helpers that build test PDFs in code. Tests check pdfrw's output with three independent tools: qpdf through pikepdf, pypdf, and PDFium through pypdfium2.

Then the bug fixes ran side by side, grouped by the part of the library they touched. Among the worst of the bugs they fixed:

Each fix has a regression test that builds its own PDF showing the bug, and notes the upstream issue it fixes.

Along the way the agents proposed or filed further tasks: AES-256 password handling, writing encrypted output, a clearer error for text that can't be written, and more tests where coverage was thin. Writing those tests turned up two more bugs, which were fixed too. The Tasks Manager checked each result before committing it, and sent five back with changes, for example to keep two module-level names that existing code might import, so the public API stayed compatible.

Porting Upstream Pull Requests

pdfrw had many open pull requests that were never merged. After the revival finished, the user wrote a second prompt, asking for the worthwhile ones to be ported before publishing, with each one credited to its author. It named which to apply, which to reimplement against the changed code, and which the run had already covered.

The Tasks Manager split this into tasks and ran them side by side. Two pull requests applied as submitted, and those commits carry the pull request's author as the commit's author. Ten more were reimplemented to fit the changed code, and credit their authors with Co-authored-by lines. Among them, PdfReader.remove_page now works on nested page trees, not only flat ones, keeps page labels, and drops references to the removed page. Checking which pull requests were already covered turned up a bug that one of them had found, where an indirect object holding a bare number made that number into a reference everywhere in the file. It was fixed and credited to that pull request's author. The changelog lists every open pull request and what became of it, including the two that weren't taken and why.

The Result

pdfrw-ng is pdfrw 0.4's API under a new distribution name, with the same pdfrw import name, for Python 3.11 and later. Its test suite of 483 tests builds its own PDFs, runs offline, and covers 90% of the library's lines, up from 28%:

Shown above: Test coverage of each module, upstream pdfrw in grey and pdfrw-ng in green.

Each fix notes the upstream issue it fixes, in its commit and in the changelog. The README credits Patrick Maupin and the other original authors, and the original license file is unchanged. examples/booklet.py is set up as Wing's main entry point.

Notes

pdfrw-ng has not been published on PyPI, and the run treated it as a test, not a release. The suite was run on CPython 3.11 through 3.14 on one machine. Its CI configuration covers Linux, macOS and Windows but has not run yet, and checking it on Windows and CPython 3.15 is one of the 7 tasks left for later. The others are improvements, such as bookmark helpers and dropping the Python 2 compatibility code.

This run was easier than writing a new app in some ways and harder in others. The bug reports gave the agents clear targets that could be reproduced and tested, and most tasks finished in a few minutes. But many tasks touched the same few files, so the plan named the files each task owned or shared, and the Tasks Manager once told a worker to leave the README alone because another task was editing it.

Wing gives agents its IDE's features as tools on its MCP servers, and the run record counts how the agents used them. The Tasks Manager made 94% of its tool calls to Wing's tools. Workers ran 61 of their 113 test runs with Wing's test tools, and all but one commit went through Wing. In 7 tasks, workers used Wing to edit Python code by function or class, finding and replacing each one in a single step. In this run they also found code with grep, find and their own search tools, 247 times, and mostly looked at changes with git in the shell. Use of Wing's MCP tools in the run record has the full counts.

The run record gives, for each task, the prompt, the judgement calls and the alternatives considered, the findings filed, the commits, and the time each took. It also lists the Manager's questions and decisions and the places where it redirected a worker. run-trail/trail.json has the same data.

Try it Yourself

To repeat a run like this one, you need Wing Pro 12.1 or later and an AI agent such as Claude Code, with an account that covers sustained use. Getting Started with Autonomous Development walks through the setup, and AI Agent-Assisted Development in Wing's documentation covers the Tasks Manager in full.

To try pdfrw-ng itself, follow the install steps in its README. It replaces an installed pdfrw, since both use the same import name. In Wing, open pdfrw.wpr and run examples/make_sample.py to make a sample PDF for the examples/booklet.py entry point.