Skip to content
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

Open
kcpevey opened this issue Sep 2, 2024 · 9 comments
Open

[ENH] - Enable ability to launch an app directly from notebook #472

kcpevey opened this issue Sep 2, 2024 · 9 comments

Comments

@kcpevey
Copy link
Contributor

kcpevey commented Sep 2, 2024

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

@krassowski
Copy link
Member

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.

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.

@kcpevey
Copy link
Contributor Author

kcpevey commented Sep 9, 2024

I'm fine with whatever location makes the most sense.

@nenb
Copy link
Contributor

nenb commented Sep 18, 2024

@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 /services/japps/create-app in a new window. But then I got stuck trying to find a way to pre-populate the form. I can see at least 2 options:

  1. vendor the relevant form from jhub-apps inside of jupyterlab-nebari-mode, and extend it with functionality that allows pre-population of the form
  2. extend jhub-apps to allow pre-population of the form e.g. as query parameters in the URL (/services/japps/create-app?name=my_app&framework=panel)

1 seems like quite a bit of work to me, and also creates a synchronisation issue when the form in jhub-apps is updated.
2 seems more natural to me, but perhaps it's more than was intended for this story.

Or can you suggest another approach for pre-populating the form that I have missed?

@krassowski
Copy link
Member

I've followed Mike's approach of implementing this as a plugin in https://github.com/nebari-dev/jupyterlab-nebari-mode.

Is there a draft PR?

A question that I now have is whether pre-population of the form is a core requirement for this story?

Yes

extend jhub-apps to allow pre-population of the form e.g. as query parameters in the URL (/services/japps/create-app?name=my_app&framework=panel)

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.

2 seems more natural to me, but perhaps it's more than was intended for this story.

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 <iframe> in the main area widget.

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.

@kcpevey
Copy link
Contributor Author

kcpevey commented Sep 19, 2024

is whether pre-population of the form is a core requirement for this story?

yep

@nenb
Copy link
Contributor

nenb commented Sep 19, 2024

Is there a draft PR?

Part 1 is available at : nebari-dev/jupyterlab-nebari-mode#7

I will open Part 2 (in jhub-apps that adds query parameter functionality to the /create-apps route) tomorrow.

Hopefully Part 1 and Part 2 (after feedback + iteration) should be sufficient for v0 and allow some scope for extending to v1.

@nenb
Copy link
Contributor

nenb commented Sep 23, 2024

@kcpevey Update based on my chat with @krassowski on Friday.

There are 5 steps to complete this issue:

  1. The PR for Part 1 above is now complete. Mike is happy with it (apart from some nitpicks). For various reasons (including your earlier comment) we are now going to migrate this PR to it's own repo (see also 3. below) - https://github.com/nebari-dev/jupyterlab-jhub-apps.
  2. This afternoon I will push a PR to this repo that deals with Part 2 above.
  3. Then I will migrate the PR from step 1 to the new repo, along with some adequate snapshot testing.
  4. The PR in part 1 currently opens everything in a new tab in the browser. It would be preferable to instead open everything in a new notebook tab inside JupyterLab (i.e. adding a new Widget to the main area). Step 4 will update the code to also support this.
  5. There are some further changes required in jhub-apps to be able to support opening everything in a new notebook tab. Specifically, an addition of a switch for 'headless' mode for certain pages.

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.

@kcpevey
Copy link
Contributor Author

kcpevey commented Sep 23, 2024

@nenb sounds good. Thanks for the update!

@nenb
Copy link
Contributor

nenb commented Oct 24, 2024

@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 filepath field. We decided that this was the most useful path to populate initially, as it can be confusing to users how it should be populated..

If, after user feedback, further fields are required to be pre-populated, this should be straightforward to achieve.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants