Changes between Version 1 and Version 2 of Ticket #1698, comment 13


Ignore:
Timestamp:
2014-09-07T21:02:32Z (10 years ago)
Author:
daira
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1698, comment 13

    v1 v2  
    33Note that the argument to "`coverage run`" is a Python script, not an arbitrary executable. It will always be run in-process, i.e. in the same Python interpreter instance as `coverage`.
    44
    5 The reason why "`coverage run bin/tahoe debug trial`" does not work is that `bin/tahoe` runs the "`debug trial`" command in a subprocess, in order to pass the correct `PYTHONPATH`. `coverage` isn't capable of capturing coverage information for subprocesses. (Running it directly wouldn't help, because `coverage` does not have the right `PYTHONPATH` and so neither does any script it runs.) So `src/allmydata/__init__.py` complains and exits, as it should.
     5[Edit: corrected the following paragraph.]
     6
     7The reason why "`coverage run bin/tahoe debug trial`" does not work is that `bin/tahoe` runs the support script that does the tests in a subprocess, in order to pass the correct `PYTHONPATH`. So the coverage that is captured is only that of the `bin/tahoe` script, since `coverage` isn't capable of capturing coverage information for subprocesses. (Running it directly wouldn't help, because `coverage` does not have the right `PYTHONPATH` and so neither does any script it runs.)
    68
    79When `coverage` is run from `bin/tahoe` using `@`, it gets the correct `PYTHONPATH`, and so does the script that it runs. This was one of the main motivations for adding `@`. Importantly, `bin/tahoe` will expand `@tahoe` to the absolute path of the support script --not its own path-- before invoking `coverage`. If it expanded `@tahoe` to its own absolute path, then the tests would be running in a subprocess of `coverage` which wouldn't work for the same reason as above.