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. |
jacobtomlinson
left a comment
There was a problem hiding this comment.
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/python3can only point to one at a time.distributedrunsdaskfrom 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 fordistributedto be running under (e.g.) Python 3.13 while/usr/bin/daskhas 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
daskusingsys.executablefixes this. It's only strictly necessary to change the invocations ofdaskindistributed.deploy.subprocess, but it seemed better to apply the same change to the whole codebase for consistency.pre-commit run --all-files