-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ENH] - Enable ability to launch an app directly from notebook #472
Comments
If we want it to be used as standalone extension with jhub-apps but without nebari, then a new repo make most sense. Otherwise, it could be a new plugin in https://github.com/nebari-dev/jupyterlab-nebari-mode. |
I'm fine with whatever location makes the most sense. |
@kcpevey I've followed Mike's approach of implementing this as a plugin in https://github.com/nebari-dev/jupyterlab-nebari-mode. A question that I now have is whether pre-population of the form is a core requirement for this story? (I assume it is, but just confirming that this is the case, as it will reduce the work involved quite a bit I think.) @krassowski How would you suggest that I implement pre-population of the form (assuming @kcpevey confirms this above)? What I initially had planned was to add a new plugin command that would open the response from
1 seems like quite a bit of work to me, and also creates a synchronisation issue when the form in Or can you suggest another approach for pre-populating the form that I have missed? |
Is there a draft PR?
Yes
This one. But in the first iteration we are interested in just populating the path to the notebook/file (as this is the most difficult to type out and easiest to implement). In second iteration we can add the path to environment. In the third one let's try to guess framework. The idea is to get something out first to allow for user testing. The name would always be populated by the user I guess.
Exactly. In v0 we can just open a new tab with the pre-populated URL. In v1 we can try to embed the form using In either case we are not interested in vendoring the form - using the existing form with query parameters is the way to go. In the final version with an iframe we may add a parameter simplifying some styling so that form looks better in Jupyter main area widget, but that is low priority. |
yep |
Part 1 is available at : nebari-dev/jupyterlab-nebari-mode#7 I will open Part 2 (in Hopefully Part 1 and Part 2 (after feedback + iteration) should be sufficient for v0 and allow some scope for extending to v1. |
@kcpevey Update based on my chat with @krassowski on Friday. There are 5 steps to complete this issue:
The goal is to have steps 1-4 completed by Wednesday midday ET. I will then sync with Mike during our 1-1 on progress. Step 5 may need to be taken on by others - I will discuss this with Mike on Wednesday, and will circle back here. |
@nenb sounds good. Thanks for the update! |
@kcpevey All steps for this issue have now been completed following nebari-dev/jupyterlab-jhub-apps#12 (comment). It will probably be released sometime next week. The current version will only populate the If, after user feedback, further fields are required to be pre-populated, this should be straightforward to achieve. |
Feature description
As a developer creating an app, I'm working in JLab for development. Once I'm done writing my app, I want to deploy it. The workflow of going to back to the jhub-apps homepage (a completely different interface) and then having to fill the form manually could be improved.
When we are in the JLab space, we have most of the information required for the form. It would be nice to just be able to click a button on the notebook or select a menu item and be automatically redirected to the deploy app form with most of the information filled in.
Value and/or benefit
This would make app launching simpler for users and make it faster since users don't have to fill out so much of the form.
Anything else?
We need to cover launching apps from both notebooks and py files.
We've discussed making this a separate jupyterlab extension. It will likely need its own repo, but this seemed the most logical place to track the work for now.
There has been some design work on this - https://www.figma.com/design/jYxLqubOT7pwLFlM7hCDps/CDAO-Nebari?node-id=7438-17969&t=xVr5sESQVIRWCjgz-1
The text was updated successfully, but these errors were encountered: