@srhb, thanks for your PR! By analyzing the history of the files in this pull request, we identified @FRidh to be a potential reviewer.

As you mentioned on IRC this is an application and not a library. Therefore, it should indeed be called from all-packages.nix. However, in that case it shouldn't be in python-packages.nix but somewhere else in the Nixpkgs tree depending on what kind of application this is.

Sorry about that, I misunderstood you. I've moved it to tools/text following the logic that it is similar in scope of use to things like diffutils that already live there. The tool conditionally adds/removes commented sections from eg. dotfiles based on certain predicates.

Good. The final step is tests. By default buildPythonPackage runs tests and I saw 0 zero tests were found. Unfortunately there's many different ways tests are invoked, so often the default test runner (python setup.py test) won't find any.

I see you added pytest. Likely tests are run with py.test. Typically it helps checking the archive to see how tests are supposed to run. Also, because sometimes no tests are actually included, in which case we set doCheck = false; and include a comment explaining why the tests are disabled.

It looks like the tests are broken upstream, so enabling custom testing would break the build. Would it be preferable if I close this PR for now and return later when it has been fixed, rather than adding the package with doCheck = false;?

No, adding doCheck = false; now is fine. Do you want to maintain this package? If so, you can add the maintainer field. Don't forget to squash the commits eventually.

Squashed, tests disabled and I've added myself as maintainer.