I participated in the PyCascades sprint day yesterday, offering up coverage.py as a project. I was pretty sure it wasn’t beginner-friendly, but the sprint was useful because it pointed out specific ways that it was not, and we fixed some of them.

The sprint was all-remote, and we had about a half-dozen people online. They dug in energetically, trying to set up a development environment. The first thing we realized together was that the Contributing page needed updating: it didn’t mention making a GitHub fork, it over-emphasized virtualenvs without explaining them, and it was too focused on specific versions of Python.

Phebe Polk fixed that with one of the merged pull requests for the day: #1591 Update contribution instructions.

Another confusing point was that people might come to the coverage.py README page with two different goals: people wanting to use the tool, and people wanting to contribute to the tool. This may seem like a small point, but any friction is worth eliminating, and it was done with a small pull request by Kassandra Keeton.

Separately, Neil Pilgrim saw I had both a setup.cfg and pyproject.toml, so he moved my pytest settings from the old-style file to the new: build: Migrate pytest configuration to pyproject.toml.

One other problem people encountered was due to my docs build including sphinxcontrib.spelling. That’s there for spell checking, but it relies on an OS-native installation of enchant that most new contributors won’t have. It was a simple matter to use the extension only when spell checking, unblocking the default execution of tox environments, and removing one more speed bump.

My biggest learning through this process was about hashed pins in my dependency files. They are a security feature, but get in the way when people install on different operating systems or versions of Python. I’m convinced now they are a bad idea for coverage.py. I haven’t made any changes, but I ranted in an issue about it. There are more details there if you are interested.

I’m still eager to hear about people’s experience with starting to use coverage.py or contribute to it. It’s not an easy project to make changes to, but at least we can make it easier to get to the point of looking at the code.

The sprint didn’t go exactly in the direction I thought it would, but I enjoyed talking over these issues with people, hanging out with them, and fixing some friction points along the way.