anki/qt/tests/run_format.py

67 lines
1.5 KiB
Python
Raw Normal View History

2021-04-13 10:45:05 +02:00
# Copyright: Ankitects Pty Ltd and contributors
# License: GNU AGPL, version 3 or later; http://www.gnu.org/licenses/agpl.html
import os
import subprocess
import sys
if __name__ == "__main__":
isort_ini = sys.argv[1]
isort_ini = os.path.abspath(isort_ini)
fix = len(sys.argv) > 2
serialize black invocations On a Linux machine here, the tests consistently fail when two copies of black are run at once: % bazel test //qt:format_check //pylib:format_check --cache_test_results=no ==================== Test output for //qt:format_check: Process SyncManager-1: Traceback (most recent call last): File "/home/dae/.cache/bazel/_bazel_dae/fc22e40cbbf8b7d16ac57a00991b1ef1/external/python/lib/python3.9/multiprocessing/process.py", line 315, in _bootstrap self.run() File "/home/dae/.cache/bazel/_bazel_dae/fc22e40cbbf8b7d16ac57a00991b1ef1/external/python/lib/python3.9/multiprocessing/process.py", line 108, in run self._target(*self._args, **self._kwargs) File "/home/dae/.cache/bazel/_bazel_dae/fc22e40cbbf8b7d16ac57a00991b1ef1/external/python/lib/python3.9/multiprocessing/managers.py", line 583, in _run_server server = cls._Server(registry, address, authkey, serializer) File "/home/dae/.cache/bazel/_bazel_dae/fc22e40cbbf8b7d16ac57a00991b1ef1/external/python/lib/python3.9/multiprocessing/managers.py", line 156, in __init__ self.listener = Listener(address=address, backlog=16) File "/home/dae/.cache/bazel/_bazel_dae/fc22e40cbbf8b7d16ac57a00991b1ef1/external/python/lib/python3.9/multiprocessing/connection.py", line 453, in __init__ self._listener = SocketListener(address, family, backlog) File "/home/dae/.cache/bazel/_bazel_dae/fc22e40cbbf8b7d16ac57a00991b1ef1/external/python/lib/python3.9/multiprocessing/connection.py", line 596, in __init__ self._socket.bind(address) OSError: [Errno 98] Address already in use I dug briefly into Black's code, but suspect this is actually an issue with the multiprocessing library. Didn't have time to investigate it further; this workaround will do for now. (One day I'll get around to merging those separate scripts into a single one. One day. :-))
2022-02-11 05:47:05 +01:00
if sys.platform == "linux":
2022-02-11 10:46:38 +01:00
import fcntl
serialize black invocations On a Linux machine here, the tests consistently fail when two copies of black are run at once: % bazel test //qt:format_check //pylib:format_check --cache_test_results=no ==================== Test output for //qt:format_check: Process SyncManager-1: Traceback (most recent call last): File "/home/dae/.cache/bazel/_bazel_dae/fc22e40cbbf8b7d16ac57a00991b1ef1/external/python/lib/python3.9/multiprocessing/process.py", line 315, in _bootstrap self.run() File "/home/dae/.cache/bazel/_bazel_dae/fc22e40cbbf8b7d16ac57a00991b1ef1/external/python/lib/python3.9/multiprocessing/process.py", line 108, in run self._target(*self._args, **self._kwargs) File "/home/dae/.cache/bazel/_bazel_dae/fc22e40cbbf8b7d16ac57a00991b1ef1/external/python/lib/python3.9/multiprocessing/managers.py", line 583, in _run_server server = cls._Server(registry, address, authkey, serializer) File "/home/dae/.cache/bazel/_bazel_dae/fc22e40cbbf8b7d16ac57a00991b1ef1/external/python/lib/python3.9/multiprocessing/managers.py", line 156, in __init__ self.listener = Listener(address=address, backlog=16) File "/home/dae/.cache/bazel/_bazel_dae/fc22e40cbbf8b7d16ac57a00991b1ef1/external/python/lib/python3.9/multiprocessing/connection.py", line 453, in __init__ self._listener = SocketListener(address, family, backlog) File "/home/dae/.cache/bazel/_bazel_dae/fc22e40cbbf8b7d16ac57a00991b1ef1/external/python/lib/python3.9/multiprocessing/connection.py", line 596, in __init__ self._socket.bind(address) OSError: [Errno 98] Address already in use I dug briefly into Black's code, but suspect this is actually an issue with the multiprocessing library. Didn't have time to investigate it further; this workaround will do for now. (One day I'll get around to merging those separate scripts into a single one. One day. :-))
2022-02-11 05:47:05 +01:00
file = open("/tmp/anki-black", "w")
fcntl.lockf(file, fcntl.LOCK_EX)
if fix:
os.chdir(os.path.join(os.environ["BUILD_WORKSPACE_DIRECTORY"], "qt"))
args = []
else:
folder = os.path.join(os.path.dirname(__file__), "..")
os.chdir(folder)
args = ["--diff", "--check"]
# work around issue with latest black
2021-05-18 22:19:09 +02:00
if sys.platform == "win32" and "HOME" in os.environ:
os.environ["USERPROFILE"] = os.environ["HOME"]
retcode = subprocess.run(
[
sys.executable,
"-m",
"black",
"-t",
2021-10-04 07:05:15 +02:00
"py39",
"--exclude=aqt/forms|colors|_gen",
"aqt",
"tests",
"tools",
updates to the build process and binary bundles All platforms: - rename scripts/ to tools/: Bazelisk expects to find its wrapper script (used by the Mac changes below) in tools/. Rather than have a separate scripts/ and tools/, it's simpler to just move everything into tools/. - wheel outputs and binary bundles now go into .bazel/out/dist. While not technically Bazel build products, doing it this way ensures they get cleaned up when 'bazel clean' is run, and it keeps them out of the source folder. - update to the latest Bazel Windows changes: - bazel.bat has been removed, and tools\setup-env.bat has been added. Other scripts like .\run.bat will automatically call it to set up the environment. - because Bazel is now on the path, you can 'bazel test ...' from any folder, instead of having to do \anki\bazel. - the bat files can handle being called from any working directory, so things like running "\anki\tools\python" from c:\ will work. - build installer as part of bundling process Mac changes: - `arch -arch x86_64 bazel ...` will now automatically use a different build root, so that it is cheap to switch back and forth between archs on a new Mac. - tools/run-qt* will now automatically use Rosetta - disable jemalloc in Mac x86 build for now, as it won't build under Rosetta (perhaps due to its build scripts using $host_cpu instead of $target_cpu) - create app bundle as part of bundling process Linux changes: - remove arm64 orjson workaround in Linux bundle, as without a readily-available, relatively distro-agonstic PyQt/Qt build we can use, the arm64 Linux bundle is of very limited usefulness. - update Docker files for release build - include fcitx5 in both the qt5 and qt6 bundles - create tarballs as part of the bundling process
2022-01-30 01:50:14 +01:00
"bundle",
]
+ args,
check=False,
).returncode
if retcode != 0:
sys.exit(retcode)
retcode = subprocess.run(
[
sys.executable,
"-m",
"isort",
"--settings-path",
isort_ini,
"aqt",
"tests",
"tools",
updates to the build process and binary bundles All platforms: - rename scripts/ to tools/: Bazelisk expects to find its wrapper script (used by the Mac changes below) in tools/. Rather than have a separate scripts/ and tools/, it's simpler to just move everything into tools/. - wheel outputs and binary bundles now go into .bazel/out/dist. While not technically Bazel build products, doing it this way ensures they get cleaned up when 'bazel clean' is run, and it keeps them out of the source folder. - update to the latest Bazel Windows changes: - bazel.bat has been removed, and tools\setup-env.bat has been added. Other scripts like .\run.bat will automatically call it to set up the environment. - because Bazel is now on the path, you can 'bazel test ...' from any folder, instead of having to do \anki\bazel. - the bat files can handle being called from any working directory, so things like running "\anki\tools\python" from c:\ will work. - build installer as part of bundling process Mac changes: - `arch -arch x86_64 bazel ...` will now automatically use a different build root, so that it is cheap to switch back and forth between archs on a new Mac. - tools/run-qt* will now automatically use Rosetta - disable jemalloc in Mac x86 build for now, as it won't build under Rosetta (perhaps due to its build scripts using $host_cpu instead of $target_cpu) - create app bundle as part of bundling process Linux changes: - remove arm64 orjson workaround in Linux bundle, as without a readily-available, relatively distro-agonstic PyQt/Qt build we can use, the arm64 Linux bundle is of very limited usefulness. - update Docker files for release build - include fcitx5 in both the qt5 and qt6 bundles - create tarballs as part of the bundling process
2022-01-30 01:50:14 +01:00
"bundle",
]
+ args,
check=False,
).returncode
if retcode != 0:
sys.exit(retcode)