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
With bokeh 3.0.2, the task stream doesn't show up, nor do the 'tasks processing' bars. (I've more commonly seen that a few tasks intermittently show up on the task stream, but most are missing. The 'tasks processing' bars always seem to be broken.)
After pip install 'bokeh<3':
In [1]: importdistributedIn [2]: importdask.arrayasdaIn [3]: client=distributed.Client()
In [4]: da.random.random(200_000, chunks=100).sum().compute()
I see this with both macOS and linux running the scheduler, both Chrome and Safari as the browser.
Thanks @jrbourbeau. Until this is fixed though, shouldn't we set an upper bound on Bokeh versions? distributed isn't compatible with bokeh 3, so the appropriate thing to do from a packaging standpoint would be to set a limit. That is, revert dask/dask#9659 and the yaml changes in #5648. Getting a broken dashboard when installing dask in a new environment isn't a great user experience.
As you saw, previously we were setting an upper bound and then we added bokeh=3 compatibility code and removed the upper bound. You bring up a fair point that, while the compatibility code was needed, given we know there are some plot rendering issues, removing the bokeh<3 was probably too premature.
FWIW as bokeh is an optional dependency, we can't 100% prevent users from installing bokeh=3 in all cases. For example, I think pip install distributed bokeh will still pull in latest releases, but IIRC there are some things we can do with conda in this situation (maybe run_constrained?). That said, we do have full control over certain installation options (i.e. pip install dask[complete], conda install dask) and a best-effort approach there would still add value.
@charlesbluca do you have bandwidth / interest in reinstating those bokeh<3 constraints? No worries if not
EDIT: Also, @gjoseph92@ncclementi if either of you have bandwidth to make these changes, that would also be welcome
we can't 100% prevent users from installing bokeh=3 in all cases
Agreed, I don't think we can do anything about that. I tried experimenting with setting bounds on optional dependencies, but unsurprisingly pip doesn't care about them unless you're installing the option.
Mostly having dask[complete] and conda install dask give you the right thing seems like the primary concern right now. I'm happy to open some PRs adding the pin back.
Activity
jrbourbeau commentedon Nov 17, 2022
Thanks @gjoseph92 -- closing as a duplicate of #7173
gjoseph92 commentedon Nov 17, 2022
Thanks @jrbourbeau. Until this is fixed though, shouldn't we set an upper bound on Bokeh versions? distributed isn't compatible with bokeh 3, so the appropriate thing to do from a packaging standpoint would be to set a limit. That is, revert dask/dask#9659 and the yaml changes in #5648. Getting a broken dashboard when installing dask in a new environment isn't a great user experience.
jrbourbeau commentedon Nov 17, 2022
As you saw, previously we were setting an upper bound and then we added
bokeh=3compatibility code and removed the upper bound. You bring up a fair point that, while the compatibility code was needed, given we know there are some plot rendering issues, removing thebokeh<3was probably too premature.FWIW as
bokehis an optional dependency, we can't 100% prevent users from installingbokeh=3in all cases. For example, I thinkpip install distributed bokehwill still pull in latest releases, but IIRC there are some things we can do withcondain this situation (mayberun_constrained?). That said, we do have full control over certain installation options (i.e.pip install dask[complete],conda install dask) and a best-effort approach there would still add value.@charlesbluca do you have bandwidth / interest in reinstating those
bokeh<3constraints? No worries if notEDIT: Also, @gjoseph92 @ncclementi if either of you have bandwidth to make these changes, that would also be welcome
gjoseph92 commentedon Nov 17, 2022
Agreed, I don't think we can do anything about that. I tried experimenting with setting bounds on optional dependencies, but unsurprisingly pip doesn't care about them unless you're installing the option.
Mostly having
dask[complete]andconda install daskgive you the right thing seems like the primary concern right now. I'm happy to open some PRs adding the pin back.gjoseph92 commentedon Nov 17, 2022
bokeh=3support dask#9673bokeh=3support #7329