-
-
Notifications
You must be signed in to change notification settings - Fork 719
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run dask with a matching interpreter #8975
Conversation
When Debian is in the process of migrating from one Python version to another, there's a transitional period when we run tests on each of two Python versions, although `/usr/bin/python3` can only point to one at a time. `distributed` runs `dask` from the executable search path, and when it's installed as a system package rather than in a virtual environment, it's possible during this transitional period for `distributed` to be running under (e.g.) Python 3.13 while `/usr/bin/dask` has a `#!` line that causes it to be run under (e.g.) Python 3.12. This results in the following obscure failure mode in some tests in `distributed/deploy/tests/test_subprocess.py`: ______________________________ test_basic ______________________________ @pytest.mark.skipif(WINDOWS, reason="distributed#7434") @gen_test() async def test_basic(): async with SubprocessCluster( asynchronous=True, dashboard_address=":0", scheduler_kwargs={"idle_timeout": "5s"}, worker_kwargs={"death_timeout": "5s"}, ) as cluster: async with Client(cluster, asynchronous=True) as client: > result = await client.submit(lambda x: x + 1, 10) distributed/deploy/tests/test_subprocess.py:27: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <Future: cancelled, key: lambda-e426db6b5bc630ab037e145b5e8f631c>, raiseit = True async def _result(self, raiseit=True): await self._state.wait() if self.status == "error": exc = clean_exception(self._state.exception, self._state.traceback) if raiseit: typ, exc, tb = exc > raise exc.with_traceback(tb) E SystemError: no locals found when setting up annotations distributed/client.py:410: SystemError Explicitly running `dask` using `sys.executable` fixes this. It's only _strictly_ necessary to change the invocations of `dask` in `distributed.deploy.subprocess`, but it seemed better to apply the same change to the whole codebase for consistency.
OK, |
I'm not familiar with conda, so I can't help with the |
Unit Test ResultsSee test report for an extended history of previous test failures. This is useful for diagnosing flaky tests. 27 files ±0 27 suites ±0 11h 33m 19s ⏱️ + 8m 2s For more details on these failures, see this check. Results for commit 6d6411f. ± Comparison against base commit 1b92625. ♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a very niche scenario. However this seems like a reasonable change, explicit is better than implicit.
…matching-interpreter
I've just pulled from |
Other failures look unrelated. Merging. |
When Debian is in the process of migrating from one Python version to another, there's a transitional period when we run tests on each of two Python versions, although
/usr/bin/python3
can only point to one at a time.distributed
runsdask
from the executable search path, and when it's installed as a system package rather than in a virtual environment, it's possible during this transitional period fordistributed
to be running under (e.g.) Python 3.13 while/usr/bin/dask
has a#!
line that causes it to be run under (e.g.) Python 3.12. This results in the following obscure failure mode in some tests indistributed/deploy/tests/test_subprocess.py
:Explicitly running
dask
usingsys.executable
fixes this. It's only strictly necessary to change the invocations ofdask
indistributed.deploy.subprocess
, but it seemed better to apply the same change to the whole codebase for consistency.pre-commit run --all-files