On Tue, Oct 15, 2013 at 1:47 PM, Thomas Goirand z...@debian.org 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 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
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 binary
On 10/16/2013 01:52 PM, Tristan Seligmann wrote:
On Tue, Oct 15, 2013 at 1:47 PM, Thomas Goirand z...@debian.org 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
Hi all,
On Tue, Oct 15, 2013 at 7:08 AM, Thomas Goirand z...@debian.org 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
Thomas Goirand z...@debian.org 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
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.
So
On Tue, Oct 15, 2013 at 11:19 AM, Thomas Goirand z...@debian.org 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
On Tue, Oct 15, 2013 at 1:19 PM, Thomas Goirand z...@debian.org 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
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 3:04 PM, Jakub Wilk jw...@debian.org 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
On Tue, Oct 15, 2013 at 3:14 PM, Dmitry Shachnev mity...@gmail.com 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
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
On 10/15/2013 07:01 PM, Dmitry Shachnev wrote:
On Tue, Oct 15, 2013 at 1:19 PM, Thomas Goirand z...@debian.org 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:
* Dmitry Shachnev mity...@gmail.com, 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
$
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
Thomas Goirand z...@debian.org writes:
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?
Please let's focus on providing /usr/bin/coverage.
I'm not convinced
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, at the
exception that /usr/bin/coverage isn't provided by the package. Ben
opened but #726255 to track the issue.
My proposal fix was
18 matches
Mail list logo
