--coverage fail when the package name is different from the project name

[Chmouel Boudjnah]

On a personal blog my setup.cfg my project/software name is :

[metadata]
name = package-foo
[...]
[files]
packages =
  foo

my package name is actually called foo locally on my filesystem and this is what I would like to test. testrunner force it to have the package from distribution.get_name() (i.e: package name) according to this code :

http://pastie.org/pastes/8973154/text?key=u4oiulumxb5rt9k7okrgoq

Here is patch that add a new option --coverage-package-name= to be able to set it to what we want :

http://pastie.org/pastes/8973213/text?key=5spizx2cvqsjamotsjaaza

(I think nosetests has a similiar option as well).

Let me know what do you think so I can submit it.

[Robert Collins (lifeless)]

We can do this sure. I think you'll find that pbr has taken over the setup.cfg glue though. IMBW.

[Chmouel Boudjnah (chmouel)]

I think I am using pbr, I have only this with my setup.py

setuptools.setup(setup_requires=['pbr>=0.5.21,<1.0'],
                 pbr=True)

and this in my setup.cfg :

[global]
setup-hooks =
    pbr.hooks.setup_hook

oh well, i'll just ping monty :) but i think this patch may still be worthwhile

[Marc Abramowitz (msabramo)]

Sounds like the same (or similar) issue as:

https://bugs.launchpad.net/pbr/+bug/1310008

I submitted a changeset for this to pbr:

https://review.openstack.org/89205

[Marc Abramowitz (msabramo)]

https://review.openstack.org/#/c/89205/ for pbr was merged. So it might be nice to support this in testrepository for consistency.

[Marc Abramowitz (msabramo)]

Monty released pbr 0.8.1 with --coverage-package-name option (thanks, Monty!)