sapling/eden/scm/tests/sitecustomize.py

from __future__ import absolute_import

import os


if os.environ.get("COVERAGE_PROCESS_START"):
    try:
        import coverage
        import uuid

        covpath = os.path.join(os.environ["COVERAGE_DIR"], "cov.%s" % uuid.uuid1())
        cov = coverage.coverage(data_file=covpath, auto_data=True)
        cov._warn_no_data = False
        cov._warn_unimported_source = False
        cov.start()
    except ImportError:
        pass
py3: use absolute_import in sitecustomize.py 2016-04-16 05:34:21 +03:00			`from __future__ import absolute_import`
codemod: join the auto-formatter party Summary: Turned on the auto formatter. Ran `arc lint --apply-patches --take BLACK */.py`. Then run `arc lint` again so some other autofixers like spellchecker etc. looked at the code base. Manually accept the changes whenever they make sense, or use a workaround (ex. changing "dict()" to "dict constructor") where autofix is false positive. Disabled linters on files that are hard (i18n/polib.py) to fix, or less interesting to fix (hgsubversion tests), or cannot be fixed without breaking OSS build (FBPYTHON4). Conflicted linters (test-check-module-imports.t, part of test-check-code.t, test-check-pyflakes.t) are removed or disabled. Duplicated linters (test-check-pyflakes.t, test-check-pylint.t) are removed. An issue of the auto-formatter is lines are no longer guarnateed to be <= 80 chars. But that seems less important comparing with the benefit auto-formatter provides. As we're here, also remove test-check-py3-compat.t, as it is currently broken if `PYTHON3=/bin/python3` is set. Reviewed By: wez, phillco, simpkins, pkaush, singhsrb Differential Revision: D8173629 fbshipit-source-id: 90e248ae0c5e6eaadbe25520a6ee42d32005621b 2018-05-26 07:34:37 +03:00
run-tests: collect aggregate code coverage Before this patch, every Python process during a code coverage run was writing coverage data to the same file. I'm not sure if the coverage package even tries to obtain a lock on the file. But what I do know is there was some last write wins leading to loss of code coverage data, at least with -j > 1. This patch changes the code coverage mechanism to be multiple process safe. The mechanism for initializing code coverage via sitecustomize.py has been tweaked so each Python process will produce a separate coverage data file on disk. Unless two processes generate the same random value, there are no race conditions writing to the same file. At the end of the test run, we combine all written files into an aggregate report. On my machine, running the full test suite produces a little over 20,000 coverage files consuming ~350 MB. As you can imagine, it takes several seconds to load and merge these coverage files. But when it is done, you have an accurate picture of the aggregate code coverage for the entire test suite, which is ~60% line coverage. 2015-03-28 10:47:58 +03:00			`import os`

codemod: join the auto-formatter party Summary: Turned on the auto formatter. Ran `arc lint --apply-patches --take BLACK */.py`. Then run `arc lint` again so some other autofixers like spellchecker etc. looked at the code base. Manually accept the changes whenever they make sense, or use a workaround (ex. changing "dict()" to "dict constructor") where autofix is false positive. Disabled linters on files that are hard (i18n/polib.py) to fix, or less interesting to fix (hgsubversion tests), or cannot be fixed without breaking OSS build (FBPYTHON4). Conflicted linters (test-check-module-imports.t, part of test-check-code.t, test-check-pyflakes.t) are removed or disabled. Duplicated linters (test-check-pyflakes.t, test-check-pylint.t) are removed. An issue of the auto-formatter is lines are no longer guarnateed to be <= 80 chars. But that seems less important comparing with the benefit auto-formatter provides. As we're here, also remove test-check-py3-compat.t, as it is currently broken if `PYTHON3=/bin/python3` is set. Reviewed By: wez, phillco, simpkins, pkaush, singhsrb Differential Revision: D8173629 fbshipit-source-id: 90e248ae0c5e6eaadbe25520a6ee42d32005621b 2018-05-26 07:34:37 +03:00
			`if os.environ.get("COVERAGE_PROCESS_START"):`
run-tests: collect aggregate code coverage Before this patch, every Python process during a code coverage run was writing coverage data to the same file. I'm not sure if the coverage package even tries to obtain a lock on the file. But what I do know is there was some last write wins leading to loss of code coverage data, at least with -j > 1. This patch changes the code coverage mechanism to be multiple process safe. The mechanism for initializing code coverage via sitecustomize.py has been tweaked so each Python process will produce a separate coverage data file on disk. Unless two processes generate the same random value, there are no race conditions writing to the same file. At the end of the test run, we combine all written files into an aggregate report. On my machine, running the full test suite produces a little over 20,000 coverage files consuming ~350 MB. As you can imagine, it takes several seconds to load and merge these coverage files. But when it is done, you have an accurate picture of the aggregate code coverage for the entire test suite, which is ~60% line coverage. 2015-03-28 10:47:58 +03:00			`try:`
			`import coverage`
tests: update sitecustomize to use uuid1() instead of randrange() The comments mention that uuid would be better, so let's go ahead and make good on an old idea. 2016-11-22 01:51:39 +03:00			`import uuid`
run-tests: collect aggregate code coverage Before this patch, every Python process during a code coverage run was writing coverage data to the same file. I'm not sure if the coverage package even tries to obtain a lock on the file. But what I do know is there was some last write wins leading to loss of code coverage data, at least with -j > 1. This patch changes the code coverage mechanism to be multiple process safe. The mechanism for initializing code coverage via sitecustomize.py has been tweaked so each Python process will produce a separate coverage data file on disk. Unless two processes generate the same random value, there are no race conditions writing to the same file. At the end of the test run, we combine all written files into an aggregate report. On my machine, running the full test suite produces a little over 20,000 coverage files consuming ~350 MB. As you can imagine, it takes several seconds to load and merge these coverage files. But when it is done, you have an accurate picture of the aggregate code coverage for the entire test suite, which is ~60% line coverage. 2015-03-28 10:47:58 +03:00
codemod: join the auto-formatter party Summary: Turned on the auto formatter. Ran `arc lint --apply-patches --take BLACK */.py`. Then run `arc lint` again so some other autofixers like spellchecker etc. looked at the code base. Manually accept the changes whenever they make sense, or use a workaround (ex. changing "dict()" to "dict constructor") where autofix is false positive. Disabled linters on files that are hard (i18n/polib.py) to fix, or less interesting to fix (hgsubversion tests), or cannot be fixed without breaking OSS build (FBPYTHON4). Conflicted linters (test-check-module-imports.t, part of test-check-code.t, test-check-pyflakes.t) are removed or disabled. Duplicated linters (test-check-pyflakes.t, test-check-pylint.t) are removed. An issue of the auto-formatter is lines are no longer guarnateed to be <= 80 chars. But that seems less important comparing with the benefit auto-formatter provides. As we're here, also remove test-check-py3-compat.t, as it is currently broken if `PYTHON3=/bin/python3` is set. Reviewed By: wez, phillco, simpkins, pkaush, singhsrb Differential Revision: D8173629 fbshipit-source-id: 90e248ae0c5e6eaadbe25520a6ee42d32005621b 2018-05-26 07:34:37 +03:00			`covpath = os.path.join(os.environ["COVERAGE_DIR"], "cov.%s" % uuid.uuid1())`
run-tests: collect aggregate code coverage Before this patch, every Python process during a code coverage run was writing coverage data to the same file. I'm not sure if the coverage package even tries to obtain a lock on the file. But what I do know is there was some last write wins leading to loss of code coverage data, at least with -j > 1. This patch changes the code coverage mechanism to be multiple process safe. The mechanism for initializing code coverage via sitecustomize.py has been tweaked so each Python process will produce a separate coverage data file on disk. Unless two processes generate the same random value, there are no race conditions writing to the same file. At the end of the test run, we combine all written files into an aggregate report. On my machine, running the full test suite produces a little over 20,000 coverage files consuming ~350 MB. As you can imagine, it takes several seconds to load and merge these coverage files. But when it is done, you have an accurate picture of the aggregate code coverage for the entire test suite, which is ~60% line coverage. 2015-03-28 10:47:58 +03:00			`cov = coverage.coverage(data_file=covpath, auto_data=True)`
			`cov._warn_no_data = False`
			`cov._warn_unimported_source = False`
			`cov.start()`
			`except ImportError:`
			`pass`