Rename project #15
Comments
|
Repo and python package |
|
Ok. So how would we like to do this? Rename the repo or create a new one? |
|
This repository is, as far as I understand, quite out of date with newer JLab conventions. It would be entirely acceptable to change it's name. We would first want to verify that it still has valuable contents. |
|
Yeah that's what I gathered. So part of the reason I ask is I'm interested in refreshing it. Though admittedly I don't know all of what is needed to do that. So maybe @blink1073 can advise. 😉 Admittedly seeing a more stable JupyterLab would help motivate me, but it looks like a stable beta is a few weeks off. Being able to have the dashboard live alongside a running notebook is pretty desirable too. 😄 |
|
I agree that that would be pretty great. This extension needed some work before, I think, it would be very useful. In particular it would be handy to be able to point to a scheduler address running somewhere remotely. Perhaps there is a way that the |
|
I see. Yeah being able to configure the Client somehow would be good. Maybe there's a good example extension, which allows configuring its settings somewhere? Do you remember any other todos? |
|
I think that once a connection was made it was hard to remake a different connection (for example if the scheduler went down and came back up). Generally both this and the comment above point to a need within this project to manage connections to the scheduler. This might be a different JLab panel, or we might be able to take queues from a notebook. I got the sense that this was pretty easy to do for someone who has familiarity with JLab, but I'm not sure. |
|
@jakirkham, our walkthrough extension is here, but doesn't yet have settings (which are changing a bit in jupyterlab/jupyterlab#3167). An example core extension that uses settings is the file editor: schema, usage. |
|
Do you think this area of JupyterLab is more stable now, @blink1073? I'd be interested in getting Dask working with JupyterLab, but probably can't devote lots of time to it. So it would really help to know if this is a moving target or not to determine whether I should wait a little longer or start playing. |
|
Hi @jakirkham, I'd say wait for the next beta release. I have a goal to get most of the JS packages to 1.0 for that release, which will make maintaining extensions much easier. |
|
Sounds good. Is there somewhere I should be listening to know when it is ready or would you be able to update me here? |
|
We'll be making an announcement on the Jupyter mailing list. |
|
@jasongrout, do you have any advice on how to create a lab extension for this use case these days? Tried to look at the example link in this comment, but it appears to be broken. Also there is the open question of the best way to add settings to it. |
Is 'this use case' an extension that uses settings? CC also @afshin, @ian-r-rose who both have written either the settings system or extensions that dealt with the settings system. |
|
The use case is showing the Dask Distributed dashboard. The primary setting would be specifying the IP and port for connecting to the web server hosting this dashboard. Now that we are discussing this, vaguely remember Matt mentioning the possibility of breaking up the dashboard into various panels that could be laid out around a running notebook. Expect this would also be interesting to users, who want to track multiple activity streams (resource utilization, task scheduling/completion, etc.) while running their code. |
|
I sat down with @bollwyvl in CA last month and we had a good long chat
about this. I suggest that we open an new issue on the dask/distributed
issue tracker with a proposal for next steps. There are probably a few
things that Nick and I could dredge up from our collective memories. There
were a couple approaches, each with costs and benefits.
…On Wed, Jun 20, 2018 at 5:45 PM, jakirkham ***@***.***> wrote:
The use case is showing the Dask Distributed dashboard. The primary
setting would be specifying the IP and port for connecting to the web
server hosting this dashboard.
Now that we are discussing this, vaguely remember Matt mentioning the
possibility of breaking up the dashboard into various panels that could be
laid out around a running notebook. Expect this would also be interesting
to users, who want to track multiple activity streams (resource
utilization, task scheduling/completion, etc.) while running their code.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AASszFxQrHgdc7EqMGNA_RO4Rsf2zrqZks5t-sJwgaJpZM4LDnGQ>
.
|
|
Still a really good idea, but I haven't had a chance/need to dig in.
One of the issues, as I recall, is that the browser is not guaranteed to be
able to reach the bokeh server, nor would the host:port be known until a
client is actually created, so wouldn't be available to configure at
nbserver launch.
If the address was known at launch, one could use parts of nbserverproxy to
expose just that port.
When I looked, the existing jupyterlab_bokeh extension makes a lot of
assumptions about where the assets/document would be coming from, but it
would be ideal to be able to reuse it's machinery.
Once individual widgets are in the Dom, popout widgets are no big deal.
|
|
We're more than happy to provide the address of the dashboard from within
the Jupyter notebook. We'd be quite happy to produce some object that had
all of the relevant information. However we wouldn't want the dashboard to
be limited to the output cell of the notebook itself. We would want to
pull it off to the side.
…On Thu, Jun 21, 2018 at 6:54 PM, Nicholas Bollweg ***@***.***> wrote:
Still a really good idea, but I haven't had a chance/need to dig in.
One of the issues, as I recall, is that the browser is not guaranteed to be
able to reach the bokeh server, nor would the host:port be known until a
client is actually created, so wouldn't be available to configure at
nbserver launch.
If the address was known at launch, one could use parts of nbserverproxy to
expose just that port.
When I looked, the existing jupyterlab_bokeh extension makes a lot of
assumptions about where the assets/document would be coming from, but it
would be ideal to be able to reuse it's machinery.
Once individual widgets are in the Dom, popout widgets are no big deal.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AASszKBLUe_K1_De7VM2e1pInrd9Z6G9ks5t_CQwgaJpZM4LDnGQ>
.
|
|
So I've used jupyterlab sidecar with some success for this. There are some general resize rendering issues but it's tolerable |
|
Any phosphor widget can be addToMainArea()'d... Just have to get them onto
the page in the first place.
For example, a simple mime type "application/vnd.dask.distributed.
dashboard" could be some json:
{"dashboard": "https://some server:1234/", "widgets": [{"label": "Workers",
"doc": "abc123"}, ...
]}
...Which the labextension could render as, say, a button which launched a
new dock panel tab containing all of them, where each piece offers a "pop
out" button that made a new, dedicated tab. Or whatever pattern made sense,
like starting it inline. We're getting into the gray area of what bokeh
already does, I suppose.
|
|
Are we still interested in renaming or should this be closed? |
|
I think the name is fine as is. As long as it has been published with the relevant keywords it should be discoverable |
|
We seem to have settled on dask-labextension. Closing. |
Standard naming scheme would be
jupyterlab-dask?The text was updated successfully, but these errors were encountered: