My concern on adding pytest-cov to the requirements.txt is that it may cause problems when we start packaging libtaskotron because AFAIK, pytest-cov is not available in the fedora repos.

We can deal with that when the time comes, though.

My concern on adding pytest-cov to the requirements.txt is that it may cause problems when we start packaging libtaskotron because AFAIK, pytest-cov is not available in the fedora repos.

It seems it is:

$ yum info python-pytest-cov
Loaded plugins: changelog, langpacks, refresh-packagekit
Available Packages
Name        : python-pytest-cov
Arch        : noarch
Version     : 1.6
Release     : 1.fc20
Size        : 12 k
Repo        : updates-testing/20/x86_64
Summary     : Pytest plugin for coverage reporting
URL         : https://pypi.python.org/pypi/pytest-cov
License     : MIT
Description : Py.test plugin for coverage reporting with support for both centralised and
            : distributed testing, including subprocesses and multiprocessing for Python 2.

I don't actually want to say that we need to have it as an RPM dependency (I haven't even thought about it, to be honest). For consumers of libtaskotron that doesn't probably make sense. My intention was to have a good developer environment set up easily. So we can use it as a build dependency (probably still not ideal), or drop it once we get to RPM packaging.

It seems it is:

Cool, that's changed since the last time I checked.

I don't actually want to say that we need to have it as an RPM dependency (I haven't even thought about it, to be honest). For consumers of libtaskotron that doesn't probably make sense. My intention was to have a good developer environment set up easily. So we can use it as a build dependency (probably still not ideal), or drop it once we get to RPM packaging.

I'm running off of memory here and could be wrong, but the problem is more with setuptools/distutils and the reading of requirements.txt when you call python setup.py install. There are cases where that'll error out when requirements are unmet, regardless of what's specified in the spec file.

I could be wrong, though and it's just something to keep in mind. It'd be a pretty simple change to make if it is a problem so let's deal with that if it becomes an issue.

Looks good to me, please push to develop