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.
>
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 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
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 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
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
* Thomas Goirand , 2013-10-15, 01:47:
Unless something changed recently, Debian buildds don't block Internet
access. :(
I've read multiple times that they do. Could you show a build log where
something is downloaded?
The only thing I found[0] is a bit old, but here you go:
https://buildd.debi
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 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-
* 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.
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
Dear mentors, python hackers, Debian developers
I'm maintaining buildbot[1] packages for quite some time. While
current packaging of this application is not that hard, the upcoming
0.9 release includes a new web interface organized as python module
called 'buildbot_www'. This module is in fact an
Hi all,
I'm hoping to package a couple of python modules needed by a web app
that I'm looking to run on Debian:
- ntplib
- python-iptables
I'm pretty new to Python packaging, so I'd appreciate some review once
they're ready. And what better way to get that than to join the
relevant team? :)
I
Thomas Goirand 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 Debian
On Wed, Oct 16, 2013 at 7:54 AM, Ben Finney wrote:
> I think we're going to have to (as the Debian Python community? as the
> broader Debian maintainer community?) come up with a unified approach to
> dealing with the rapidly increasing tendency for upstream releases
> bundling doing this.
Upstre
On 10/16/2013 07:32 AM, Ben Finney wrote:
>> Nearly all OpenStack projects are using testrepository. All of them
>> are using python-coverage.
>
> That sounds like an excellent central point to make the command name
> parameterisable: fix it in one place to match the Debian
> ‘python-coverage’ pac
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
Thomas Goirand writes:
> 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 act
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
Thomas Goirand writes:
> On 10/16/2013 07:32 AM, Ben Finney wrote:
> > Patching upstream's assumptions of command names is a feature of the
> > landscape for Debian packagers. I don't consider that a reason to
> > presume ‘/usr/bin/coverage’ on Debian should refer to a
> > Python-specific tool.
>
20 matches
Mail list logo
