Time to move to dask/dask?

[fjetter]

We kept this repo separate because we anticipated a lot of breakage and wanted to have a lean release cycle. I noticed that we're now pinning hard to dask. I believe the time has come where we should merge this to the main repo

cc @phofl @hendrikmakait

[phofl]

Any idea when we want to rip out the legacy implementation? That would probably simplify the move over to dask/dask

…

On Wed, Jun 19, 2024 at 7:24 PM Florian Jetter ***@***.***> wrote: We kept this repo separate because we anticipated a lot of breakage and wanted to have a lean release cycle. I noticed that we're now pinning hard to dask. I believe the time has come where we should merge this to the main repo cc @phofl <https://github.com/phofl> @hendrikmakait <https://github.com/hendrikmakait> — Reply to this email directly, view it on GitHub <#1086>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOYQZGFBANH36WXWACUBLDTZIG5GRAVCNFSM6AAAAABJSONDBWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM3DEOBVGMYTAMI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[AdamWill]

fwiw, we in fedora found this awkward too when doing python 3.13 bumps. see also: dask-distributed, which has a dep loop with dask also (it requires dask, dask's test suite requires it). I did wonder why these are all separate projects.

[fjetter]

I did wonder why these are all separate projects.

historically, dask/dask and dask/distributed had a reasonably stable API towards each other and we could release independently.

What's stopping us from doing this right now is probably mostly CI run time since dask/dask and dask/distributed have individually a very long running test suite and merging them might cripple development velocity (poor reason for this split but something that isn't trivial do deal with)

[phofl]

We are close to this now and this will happen soon. I have PRs up to remove the legacy implementation which opens the way to move dask-expr over