On 10/15/2013 07:04 PM, Jakub Wilk wrote:> Apparently two (mostly orthogonal) problems have been squeezed into a > single bug report: > > 1) Is the name /usr/bin/coverage appropriate? > 2) Can the alternatives mechanism be used to switch between the two > implementations of the coverage command line tool?
Please let's focus on providing /usr/bin/coverage. I don't really care by what mechanism, as long as the unit tests are working, and Debian behaves like upstream coverage package from pypi. We can leave the implementation details for later. Even if only python-coverage (as opposed to the python3- version) was providing it, I'd be satisfied. On 10/15/2013 06:21 PM, Tristan Seligmann wrote: > What sort of upstream "source code" would be using the /usr/bin > wrapper at all? (I ask this question without prejudice; I can > obviously imagine some ways this might happen, but I'm more interested > in the actual existing use cases that you implied, not ones that only > exist in my imagination) I'm not sure if you're talking about the *full path* bit or what. Upstream code (or at least, unit tests...) is calling "coverage" from the standard accessible $PATH. For example: zigo@ ~/os/heat/heat heat (debian/havana)# cat tox.ini | grep coverage python setup.py testr --coverage Nearly all OpenStack projects are using testrepository. All of them are using python-coverage. Many python modules are as well, and I had to patch some of them to avoid the problem (sorry, I can't remember which one right now...). I would like that it doesn't happen again, and also that our users (eg: developers trying to find out unit test coverage) can run the coverage tests without troubles. >>> * The name ‘/usr/bin/coverage’ is, IMO, far too generic to claim in >>> Debian for a Python-only development tool. >> >> While I agree in principles, there is, so far, no other package that >> claims this file. You can use "apt-file search /usr/bin/coverage" to >> check for this. The problem is that *upstream code* is using >> /usr/bin/coverage. So unless you explain this to upstream and have the >> issue fixed over there, and have it fixed in the pypi package, you >> cannot expect downstream code (users of python-coverage) to use anything >> else. > > I think this is ultimately the problem of whichever package comes > second, not python-coverage. (cf. other examples of name collisions, > like ack/ack-grep) > >> Also, if there was another package that were using /usr/bin/coverage, it >> could also use the update-alternatives thing (if it's implementing the >> same thing, of course... otherwise we have a problem). > > Presumably it would /not/ be implementing the same thing. The thing is, we can bikeshed about what *may* happen *in the future*. Though right now, there's a problem which I would like to fix. And that is very easily fixed by providing /usr/bin/coverage, while "ugly hacking" (because that's what it is about) in all other upstream projects is a much, much harder task. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/525d2b37.50...@debian.org
