That's a good point. But do we have a good alternative here? If we depend on packages like that, I see only two options:
a) ask the person to install pyfoo as an RPM (in readme)
b) ask the person to install gcc and libfoo-devel as an RPM (in readme) and pyfoo will be then compiled and installed from pypi
Approach a) is somewhat easier and does not require compilation stack and devel libraries. OTOH it requires using virtualenv with --system-site-packages, which means people get different results on different setups. That's exactly what I'm trying to eliminate (or at least reduce). E.g.
https://phab.qa.fedoraproject.org/D1111 where I can run the test suite from makefile and you can't, and it's quite difficult to figure out why.
With b) approach, you need compilation stack on the system. I don't think it's such a huge problem, because you're a developer after all. The advantage is that virtualenv can be created without --system-site-packages, which means locally installed libraries do not affect the execution/test suite results. Also, pyfoo is installed with exactly the right version, further reducing differences between setups. The only thing that can differ is the version of libfoo-devel, which can affect the behavior. But the likeliness of that happening is much smaller than having pyfoo of a different version or pulling any deps from the system site packages.