Changes between Version 2 and Version 3 of Ticket #1698, comment 13
- Timestamp:
- 2014-09-07T21:03:32Z (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #1698, comment 13
v2 v3 7 7 The 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.) 8 8 9 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.9 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 still be running in a subprocess of `coverage` which wouldn't work for the same reason as above. 10 10 11 11 Which Python interpreter is used to run `coverage` (and therefore the tests suite) will be determined by the value of `sys.executable` in `bin/tahoe`.
