Package: python-coverage Version: 3.4-3 Submitter: Thomas Goirand <z...@debian.org> Severity: wishlist
Thomas Goirand requests the ‘python-coverage’ and (upcoming)
‘python3-coverage’ package provide alternatives for the
‘/usr/bin/coverage’ command.
Here is a detailed explanation from Thomas:
=====
This is, as much as I can tell, a standard practice in Debian to do
this. You can for example see it in python-babel, or in
python-waitress.
Let's say I have a package that build-depends on python-coverage |
python3-coverage, and then, on the system I am building on, there's
only python3-coverage installed. Build-dependencies would be
satisfied, though upstream code may want to invoke
/usr/bin/coverage. IMO, you should see this just like with sh with
multiple implementation. By calling /usr/bin/coverage, you are
saying that you don't care which version. If you explicitly call
/usr/bin/coverage3 it is because you want explicitly this one.
[…]
upstream projects do expect /usr/bin/coverage to be there, and
otherwise FTBFS. They don't really care if it is a python2 or
python3 implementation, they just need *one* of the 2
implementation, and /usr/bin/coverage to be present.
Example when building "heat" (one of the OpenStack packages I maintain):
zigo@host ~/sources/openstack/havana/heat/heat$ python setup.py \
testr --coverage
running testr
running=${PYTHON:-python} -m subunit.run discover -t ./ .
No handlers could be found for logger "heat.engine.environment"
/home/zigo/sources/openstack/havana/heat/heat/heat/common/wsgi.py:759:
DeprecationWarning: BaseException.message has been deprecated as of
Python 2.6
exc.message = gettextutils.get_localized_message(exc.message, locale)
/home/zigo/sources/openstack/havana/heat/heat/heat/tests/test_wsgi.py:226:
DeprecationWarning: BaseException.message has been deprecated as of
Python 2.6
self.assertEqual(message_es, e.exc.message)
Ran 3094 (+3024) tests in 54.360s (+54.168s)
PASSED (id=4)
As you see, it works. Now, let's remove /usr/bin/coverage:
zigo@host ~/sources/openstack/havana/heat/heat$ sudo \
update-alternatives --remove coverage /usr/bin/python2-coverage
zigo@host ~/sources/openstack/havana/heat/heat$ python setup.py \
testr --coverage
running testr
running=${PYTHON:-python} -m subunit.run discover -t ./ .
/bin/sh: 1: coverage: not found
======================================================================
FAIL: process-returncode
tags: worker-0
----------------------------------------------------------------------
Binary content:
traceback (test/plain; charset="utf8")
Ran 1 (-1546) tests
FAILED (id=5, failures=1 (+1))
error: testr failed (1)
now it fails because /usr/bin/coverage isn't present.
[…] python-coverage is *not* the name that should be in use for the
symlink in /etc/alternatives. Eg, we don't want
/etc/alternatives/python-coverage, but really
/etc/alternatives/coverage.
[…]
What you want is /etc/alternatives to contain the name of the script
file which we setup as a link in /usr/bin, so that that it can be shared
among multiple programs. Just like we have:
/usr/bin/awk -> /etc/alternatives/awk
/etc/alternatives/awk -> /usr/bin/gawk or /usr/bin/mawk
gawk and mawk are both implementation of the awk program, and are both
using update-alternatives so that they both can provide /usr/bin/awk.
This is what we want to do here, so that, no mater if python-coverage or
python3-coverage is installed, we always have a /usr/bin/coverage
implementation. In this case, there's no /etc/alternatives/gawk or a
/etc/alternatives/mawk, but a single /etc/alternative/awk. We need this
type of implementation exactly.
=====
--
\ “Pinky, are you pondering what I'm pondering?” “I think so, |
`\ Brain, but isn't a cucumber that small called a gherkin?” |
_o__) —_Pinky and The Brain_ |
Ben Finney <b...@benfinney.id.au>
signature.asc
Description: Digital signature
