Skip to content
This repository has been archived by the owner on Jan 24, 2018. It is now read-only.

Passing arguments via URL? #201

Open
gibiansky opened this issue Jan 7, 2016 · 7 comments
Open

Passing arguments via URL? #201

gibiansky opened this issue Jan 7, 2016 · 7 comments

Comments

@gibiansky
Copy link

I'd like to use tmpnb in a custom application. I need to be able to generate links, which, when clicked, take users to a notebook prepared for them. I can do the preparation by overriding --command and --image; however, somehow I have to have those links pass information to tmpnb, and, ideally, skip the homepage and go directly to a notebook.

Is there a way to do this? Specifically, the following:

  • Pass arguments to --command through the URL that the HTTP proxy gets.
  • Skip the homepage and go directly to a notebook.

Thanks!

@rgbkrk
Copy link
Member

rgbkrk commented Jan 7, 2016

Does #179 help with this?

@gibiansky
Copy link
Author

@rgbkrk That helps with part 2 (skipping the homepage). Thanks!

Is there a way to do part 1 as well? (Passing some sort of arguments to the container being run? e.g. I want the --command to vary based on some input parameters.)

@parente
Copy link
Member

parente commented Jan 7, 2016

The containers are prelaunched in tmpnb, so any URL arguments will be arriving too late to use in the command. The only time URL args are available ahead of notebook server container launch is when the user specifies a URL to a server that doesn't exist and tmpnb launches a one-off container for that user. But that's the exception, not the rule.

@gibiansky
Copy link
Author

In my application that would be the rule rather than the exception.

Is there a mechanism now to take advantage of the URL args, in any way shape or form? If not, how might I be able to add something like that? Would it be possible?

@minrk
Copy link
Member

minrk commented Jan 8, 2016

If it's supposed to affect the spawning, the spawnpool's preallocation is going to get in your way. You are going to need to either maintain multiple spawn-pools keyed by name, in which case URL args could be used to pick the pool, or kill the pools altogether, and spawn on-demand. Is your range of cases known ahead of time? If not, it would need to change a lot about how resources are allocated.

@gibiansky
Copy link
Author

The range of cases is known ahead of time, but is pretty large.

It sounds like this is somewhat out of scope of what tmpnb does right now. I can probably find a work-around.

I am using this to launch environments for analyzing specific datasets. I can probably instead create a system which generates a new notebook tailored to that dataset, uploads that notebook to the right place and redirects to that notebook, and then requires the user to run the first cell, which prepares everything as appropriate.

Thanks!

@gwincr11
Copy link

I am interested in a similar use case. Ideally I would like to be able to spin up notebooks for a user with the prior created notebooks, possibly pulled from a Github repo, a preconfigured API that helps them get access to their data via REST or some other endpoint and maybe other settings.

I would love to be able to setup environment variables or some other hook so I can pass state to the Jupyter Notebook.

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

No branches or pull requests

5 participants