Hi Diane, Hi Julian
I'm wrapping up that email as it seems to me there could be some
activity on the dask package from several people at once.
I happen to have a look at the dask.dataframe import issues,
which manifest as at least #1068422, #1069821, and #1069359.
The import problem looks fixed in 2024.5.2, but the new version
also introduced a couple of issues:
 * the following change[1] is needed to fix a test failure[2].
   [1]: https://github.com/dask/dask/pull/11177
   [2]: https://github.com/dask/dask/issues/11176
 * dask.distributed failed its supposedly flaky autopkgtest
   with an error which suggests the two packages might have to
   be uploaded in a lockstep:
If that helps, I have the package upgrade staging on my drive,
and may push to salsa after a good night of sleep. In case you
see reasons I missed for not bumping version too soon, or if you
already went through the upgrade steps already, don't hesitate
to tell me to hold my horses.
I did not focus a lot on the sphinxdoc issue described in the
newly opened #1073183. I'm not very good with dealing with
sphinxdoc, and would be more tempted to copy the bare rst files
than getting the html files back on tracks.
On Fri, 2024-06-14 at 23:16 +0200, Étienne Mollier wrote:
Hi Diane, Hi Julian
I'm wrapping up that email as it seems to me there could be some
activity on the dask package from several people at once.
Yeah I saw that and decided I was overloaded and stopped doing
anything.
Historically it was pretty important to dask and dask.distributed to be released together, upstream intends them to be matching versions, but I didn't know how to set the the dependnecy version strings to require
that.
I happen to have a look at the dask.dataframe import issues,
which manifest as at least #1068422, #1069821, and #1069359.
The import problem looks fixed in 2024.5.2, but the new version
also introduced a couple of issues:
 * the following change[1] is needed to fix a test failure[2].
   [1]: https://github.com/dask/dask/pull/11177
   [2]: https://github.com/dask/dask/issues/11176
 * dask.distributed failed its supposedly flaky autopkgtest
   with an error which suggests the two packages might have to
   be uploaded in a lockstep:
Yes very much yes. Is there a way to nag anyone trying to upload dask
to go check the harder to update distributed before uploading?
If that helps, I have the package upgrade staging on my drive,
and may push to salsa after a good night of sleep. In case you
see reasons I missed for not bumping version too soon, or if you
already went through the upgrade steps already, don't hesitate
to tell me to hold my horses.
That all seems promising to me.
I did not focus a lot on the sphinxdoc issue described in the
newly opened #1073183. I'm not very good with dealing with
sphinxdoc, and would be more tempted to copy the bare rst files
than getting the html files back on tracks.
If you want to push what you've done I might have time sunday night/
monday to look at the sphinx problem.
Dask is probably complicated enough to be a good candidate for team maintenance.
Diane
Historically it was pretty important to dask and dask.distributed to be released together, upstream intends them to be matching versions, but I didn't know how to set the the dependnecy version strings to require
that.
It makes sense. The construction pretty much looks like the
latter is supposed to be a Python submodule of the former.
* napari is failing to build from source, but I haven't
checked yet whether this was caused by introduction of the
new dask or something else.
On Sat, Jun 15, 2024 at 10:50:17AM +0200, Étienne Mollier wrote:
Historically it was pretty important to dask and dask.distributed to be released together, upstream intends them to be matching versions, but I didn't know how to set the the dependnecy version strings to require that.
It makes sense. The construction pretty much looks like the
latter is supposed to be a Python submodule of the former.
You could do something like this in the dask.distributed source
package:
Source: dask.distributed
Build-Depends: python3-dask (>> 2024.5.2), python3-dask (<< 2024.5.3~)
and in the binary python3-dask.distributed package similarly:
Depends: python3-dask (>> 2024.5.2), python3-dask (<< 2024.5.3~)
This forces the dask version to match the dask.distributed version. I
don't know how tight the version numbers need to be, but this works to
keep the packages in step with each other, and will prevent an updated
dask package from migrating if the dask.distributed package has not
been updated in parallel. Probably more effective than adding
something to README.source (though that will certainly help a bit).
Thank you for your help with dask documentation, took time to
polish what I could and uploaded dask. dask.distributed upload
is coming soon, just the time for the last pass of local build
and tests to finish.
Have a nice day, :)
On Sun, Jun 16, 2024 at 10:57:22PM +0200, Étienne Mollier wrote:
Thank you for your help with dask documentation, took time to
polish what I could and uploaded dask. dask.distributed upload
is coming soon, just the time for the last pass of local build
and tests to finish.
Have a nice day, :)
Hi Étienne,
Unfortunately, the new dask.distributed FTBFS: https://buildd.debian.org/status/package.php?p=dask.distributed
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 349 |
Nodes: | 16 (2 / 14) |
Uptime: | 117:36:00 |
Calls: | 7,612 |
Files: | 12,786 |
Messages: | 5,683,872 |