[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Claiming ‘/usr/bin/coverage’ for a Python-specific programmer tool



On 10/16/2013 02:05 PM, Ben Finney wrote:
> Thomas Goirand <zigo@debian.org> 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 actual existing use cases that you implied, not
>>> ones that only exist in my imagination)
>>
>> I'm not sure if you're talking about the *full path* bit or what.
>> Upstream code (or at least, unit tests...) is calling "coverage" from
>> the standard accessible $PATH.
> 
> If some upstream code is making many invocations of one command with a
> hard-coded name, that's an argument to work with upstream and ask them
> to parameterise their code better (and patch it until they do), so
> OS packagers can easily alter the invocations to match OS-specific
> command locations.

I think you didn't get what I was trying to explain, so I'll try again.

I didn't wrote a single upstream project uses "coverage" in multiple
places. If it was the case, indeed it would be a problem in that one
upstream project, and it wouldn't be reasonable to change the Debian
package for *one* upstream project.

What I wrote is that multiple project does. That's very different. In
the former case, you have to convince a vast number of upstream, with
multiple types of answer, ranging from "sure, give me 5 minutes and I
fix this", to "I don't care, get off my bug tracker" type of answer.
Multiply this by a non-negligible amount of project, and you get a good
picture of why I think it could be very painful.

> In which vein, you've motivated me to raise an issue for this problem
> upstream <URL:https://bitbucket.org/ned/coveragepy/issue/272/> with the
> Python Coverage library maintainer, to argue for addressing the cause of
> the problem. Thanks!

Awesome! If upstream fixes it, then downstream projects will be forced
to follow. Let's hope it works. Thanks for doing this.

Thomas


Reply to: