On 10/16/2013 01:52 PM, Tristan Seligmann wrote:
> On Tue, Oct 15, 2013 at 1:47 PM, Thomas Goirand wrote:
>> 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
>>> ob
On 10/16/2013 02:20 PM, Robert Collins wrote:
> I think it's reasonable to get OpenStack to look for python-coverage
> to run it's tests when using a system package. Or use python -m
> coverage. 'coverage' is indeed super generic and the precedent within
> Debian for the package is to call the bina
I think it's reasonable to get OpenStack to look for python-coverage
to run it's tests when using a system package. Or use python -m
coverage. 'coverage' is indeed super generic and the precedent within
Debian for the package is to call the binary 'python-coverage'.
Is there some reason we can't t
On Tue, Oct 15, 2013 at 1:47 PM, Thomas Goirand wrote:
> 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 mo
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 al
* Dmitry Shachnev , 2013-10-15, 15:14:
As I understand it, python{2,3}-coverage are NOT compatible, and therefore
they should NOT use alternatives.
Can you please explain why they are incompatible for people who never used
them (like me)?
$ echo 'print "foo"' > foo.py
$ python-coverage -x foo.
On 10/15/2013 07:01 PM, Dmitry Shachnev wrote:
> On Tue, Oct 15, 2013 at 1:19 PM, Thomas Goirand wrote:
>> If we have update-alternatives, then it's very easy for a maintainer to
>> choose which one of the 2 implementation it wants:
>>
>> Build-Depends: python-coverage
>> Build-Conflicts: python3-
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 lin
On Tue, Oct 15, 2013 at 3:14 PM, Dmitry Shachnev wrote:
>> As I understand it, python{2,3}-coverage are NOT compatible, and therefore
>> they should NOT use alternatives.
>
> Can you please explain why they are incompatible for people who never
> used them (like me)?
I think I have figured it out
On Tue, Oct 15, 2013 at 3:04 PM, Jakub Wilk wrote:
> True for docutils; however, sphinx doesn't use alternatives, and it doesn't
> do so for good reasons.
>
> The alternatives mechanisms is only suitable if both commands are
> compatible, i.e. their behavior doesn't vary with Python version. This
Apparently two (mostly orthogonal) problems have been squeezed into a single
bug report:
1) Is the name /usr/bin/coverage appropriate?
IMVHO, no, this name is too generic.
2) Can the alternatives mechanism be used to switch between the two
implementations of the coverage command line tool?
On Tue, Oct 15, 2013 at 1:19 PM, Thomas Goirand wrote:
> If we have update-alternatives, then it's very easy for a maintainer to
> choose which one of the 2 implementation it wants:
>
> Build-Depends: python-coverage
> Build-Conflicts: python3-coverage
>
> if you need /usr/bin/coverage to be pytho
On Tue, Oct 15, 2013 at 11:19 AM, 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 wil
On 10/15/2013 02:39 PM, Ben Finney wrote:
> My disagreement is several-fold:
>
> * The binary package ‘python-coverage’ is for Python 2, and
> ‘python3-coverage’ is for Python 3. These are, as I understand it,
> deliberately treated as distinct runtime systems in Debian's Python
> world.
>
Thomas Goirand writes:
> Hi everyone in the Python list!
>
> I've been working with Ben Finney on upgrading python-coverage to 3.7. I
> believe the package was in good shape before the upload
My heartfelt thanks to Thomas for working to help me improve the
packaging of Coverage 3.7 to the point
Hi all,
On Tue, Oct 15, 2013 at 7:08 AM, Thomas Goirand wrote:
> Though, #726255 still needs a resolution, and I would like to have the
> view of other Python module maintainers. Is using update-alternatives
> the way to go? Was my commit correct? Is there any other (better) way to
> do things he
16 matches
Mail list logo
