Changes between Initial Version and Version 1 of Ticket #1698, comment 13
- Timestamp:
- 2014-09-07T20:56:03Z (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #1698, comment 13
initial v1 3 3 Note 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`. 4 4 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`. (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 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. 6 6 7 7 When `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.
