I'm sorry, I've been way too busy to help much with coverage; big thanks to Ben and Thomas for working on it.
On Oct 15, 2013, at 05:19 PM, Thomas Goirand wrote: >You will *not* find any upstream source code that will be using >/usr/bin/python2-coverage or /usr/bin/python3-coverage. Absolutely all >of them will be using /usr/bin/coverage (if they need the command line >tool). Thinking that you will be able to patch all of them is both an >illusion and a waste of time IMO. I don't think I've ever deliberately used the command line invocation of coverage. It's possible that something under-the-hood has done so, but I think most invoke coverage through Python. That means that *most* of coverage should be co-installable for both Python 2 and Python 3, which implies to me that the /usr/bin/<whatever> piece could be separate binary packages, and those could conflict. I'm not sure whether that would be more convenient than using alternatives, but it might be more correct. python-coverage could provide /usr/bin/coverage-2.7 while python3-coverage could provide /usr/bin/coverage-3.3, with symlinks provided by the appropriate "-bin" package. It's not like we haven't encountered similar problems before, e.g. nosetests, and AFAICT, we pretty much ad-hoc our way through it every time. `pythonX.Y -m <package>` is the safest way to invoke things, but people still want a nice convenient /usr/bin wrapper around that. I guess we still don't have a consistent way of doing this that everyone is happy with. -Barry -- 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/20131015152757.2fd9530c@anarchist
