Make it easier to run python scripts under coverage

Issue #174 new
Ned Batchelder
repo owner created an issue

I can run a python script like this:

$ nosetests blah

But to run it under coverage, I need to use:

$ coverage run /path/to/nosetests blah

Could coverage use PATH to find the script to run?

Comments (12)

  1. Julian Berman

    I'll take this opportunity to plug zsh again :) where this is just

    coverage run =nosetests, so for me this doesn't have huge benefit (and for bash I don't think which foo is much worse).

  2. Steven Myint

    It might be nice to have an easy way to run coverage transparently in cases where you have a bash script that tests your Python program. For example, if you had a script.bash with something like

    #!/bin/bash
    
    ./foo.py bar
    ./other.py
    

    coverage run script.bash would automatically override the PATH so that #!/usr/bin/env python (in foo.py and other.py) would end up using coverage run instead of normal python.

  3. Glyph

    On #302 I mentioned some additional benefits for Windows users (the Windows equivalent of backtick syntax is heinous, and few users know about it, as well as the fact that setuptools produces .exe files at install time so you have to manually dig around for the corresponding .py file anyway).

    There's also the fact that you should never, ever use unquoted backticks, especially with which; they mean the wrong thing. If you have spaces in a $PATH entry it'll break in half.

    Consider:

    $ python -c 'import sys; print(sys.argv[1:])' `echo a b c`
    ['a', 'b', 'c']
    $ python -c 'import sys; print(sys.argv[1:])' "$(echo a b c)"
    ['a b c']
    $ python -c 'import sys; print(sys.argv[1:])' `which program`
    ['./space', 'path/program']
    $ python -c 'import sys; print(sys.argv[1:])' "`which program`"
    ['./space path/program']
    $ python -c 'import sys; print(sys.argv[1:])' "$(which program)"
    ['./space path/program']
    
  4. Glyph

    @Ned Batchelder - I think that this is a real usability annoyance (especially for Windows users, since the shell does a very bad job of it there, even if you're using bash). I'm not entirely sure how to implement it yet, but would you be opposed to a pull request that did this or do you just not want to implement it yourself?

  5. Ned Batchelder reporter

    @Glyph My reluctance is mostly just trying to keep coverage.py from taking on things it shouldn't. Adding special logic to coverage.py isn't going to solve the problem in general. What will users do when they want to run pdb, or cProfile, on their script?

    Also, you say in #302, " On the platforms I actually use this is just inspecting $PATH, but making coverage smart in this way would also allow Windows users..." That sounds like you don't use Windows. That means there isn't really an actual user requesting this feature, just you and me thinking it could possibly be useful.

    Is there some way to tackle this outside of coverage.py?

  6. Glyph

    My reluctance is mostly just trying to keep coverage.py from taking on things it shouldn't. Adding special logic to coverage.py isn't going to solve the problem in general. What will users do when they want to run pdb, or cProfile, on their script?

    Perhaps it should be a separate tiny library that can do this kind of name-to-script resolution? It would be nice if all these tools (and there are a couple in Twisted, actually) could do this.

    That sounds like you don't use Windows. That means there isn't really an actual user requesting this feature, just you and me thinking it could possibly be useful.

    I'm not a day-to-day user of Windows for software development, but I do spend a lot of time working on Windows CI servers and development VMs to run tests and coverage, and I frequently have to remember nonsense like that for command I referenced; this is a real issue for me, I assure you :).

    Is there some way to tackle this outside of coverage.py?

    I guess I'll try my hand at writing the function, and see if there's enough meat there to justify a PyPI package.

  7. Log in to comment