You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Python 3.10 support has become unsustainable in the current dask and distributed CI. Because so many packages no longer support it as of the latest version, conda environment resolution now takes in excess of 30 minutes, and any changes to the environment file end up with CI hanging completely.
I can see two ways out (one does not exclude the other):
Drop Python 3.10. Please speak up here if dropping Python 3.10 would affect you.
Migrate to a lockfile-based package manager. Personally, I've been aggressively using pixi for the last year and I'm in love with it.
Does it matter though? It exited SPEC 0 years ago.
Yes and no! It still being an officially supported version mean that people don't feel pressured to move on if they have existing working environments with it.
Hope you don't mind the drive-by comment, I'm still subscribed here from a time in the past when I was more active with Dask 😊
Migrate to a lockfile-based package manager.
For what it's worth, in the LightGBM project we've been able to keep our conda solve times manageable for end-of-life and mostly-no-longer-supported Python versions by just recording the package versions from a successful solve and always reusing that in CI. Example:
That's a lighter-weight approach than generating a full lockfile and it's a weaker test guarantee (just "there's at least 1 solvable environment with this Python version, and LightGBM's Python code is still functional when using that Python version") but we've been using that approach for a few years and it's worked pretty well so far.
Activity
crusaderky commentedon May 7, 2026
CC @dask/maintenance
martindurant commentedon May 7, 2026
Is resolution a problem in pip too? Python 3.10 itself is maintained until later this year.
crusaderky commentedon May 7, 2026
I don't think so (untested). However that would mean having one env managed by pip and the others by conda. It doesn't seem too healthy?
Does it matter though? It exited SPEC 0 years ago.
martindurant commentedon May 8, 2026
Conda stats for april show:
This is for the anaconda main channel, not the more common conda-forge, because only noarch exists on the latter (which is the blank entry, above).
martindurant commentedon May 8, 2026
Yes and no! It still being an officially supported version mean that people don't feel pressured to move on if they have existing working environments with it.
jameslamb commentedon May 8, 2026
Hope you don't mind the drive-by comment, I'm still subscribed here from a time in the past when I was more active with Dask 😊
For what it's worth, in the LightGBM project we've been able to keep our conda solve times manageable for end-of-life and mostly-no-longer-supported Python versions by just recording the package versions from a successful solve and always reusing that in CI. Example:
conda: https://github.com/lightgbm-org/LightGBM/blob/2a675f269d08fd51fad23d67a0214f574acb384e/.ci/conda-envs/ci-core-py39.txtpip: https://github.com/lightgbm-org/LightGBM/blob/2a675f269d08fd51fad23d67a0214f574acb384e/.ci/pip-envs/requirements-oldest.txtThat's a lighter-weight approach than generating a full lockfile and it's a weaker test guarantee (just "there's at least 1 solvable environment with this Python version, and LightGBM's Python code is still functional when using that Python version") but we've been using that approach for a few years and it's worked pretty well so far.