Repo2docker: Add a preStart hook

Created on 16 Jan 2018  路  12Comments  路  Source: jupyterhub/repo2docker

This would be similar to postBuild, but would be run at runtime, before execution of the actual notebook. This easily allows things such as:

  1. setting environment variables at runtime
  2. Minor adjustments that can't be performed at build time
  3. New things we haven't thought of yet!
  4. Custom parameters for notebooks / other applications

To prevent people from putting too many things here, it should have a default short timeout (5s?) to start.

The requirements for this script should be:

  1. Be marked executable, can be in any language
  2. Receives as parameters arguments to exec that it must perform as a final line to actually start the process we want (we will provide templates for this in various languages)
  3. Not run for more than x seconds.
enhancement

Most helpful comment

ping on this issue as a few people brought up a use-case @ the binder/jupyterhub talk here in Paris today:

many folks want to decouple the "content" of the repository from the "environment" needed to run that content (e.g. they want to be able to have notebooks live online independently of a Binder repo, and use the repo _just_ to define the environment needed. Then they could update notebooks without needing to re-build the Binder image each time. This could be accomplished with a script such as this one by using gitpull or something like this to pull in content after the server starts.

All 12 comments

I like this idea! Though preStart hook makes me think that it runs before the entrypoint, whereas this is really replacing the entrypoint. For that reason, I think calling it 'entrypoint' is probably more descriptive.

This would essentially populate the config specified here: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/pull/408/files#diff-ae7d3197b7e61ee3c0f22a03c39cc495R252 yeah?

I think it's a good idea since it's a common use-case.

re: naming, I'm not sure about entrypoint. I'm guessing most people don't really know what that word means.

Or "start" or "script". I'm not sure what's best. Something that indicates that this is what is launched in the container, as opposed to an isolated script run before we start, which this isn't.

What about prelaunch?

I think the opposition is to the pre- prefix. Which to me implies it is run before not instead of. My preference: launch, script, start.

+1 to launch

I'm interested in this as an extension of my work bringing datasets to Binder with Quilt. Is there any way I could help make progress on this issue? Would it be helpful for me to put a strawman PR together?

@meffij PRs are always welcome :-) may take a bit of iteration but having something to look at would probably help get feedback from the community

The general outline here would be to:

  1. Add a simple script that is ENTRYPOINT unconditionally (launch sript)
  2. If there is an executable 'start' script in the repo, the launch script will have something like exec ./start $@ (execute as command all parameters) as last line
  3. If there isn't, it would just be exec $@ without the ./start

We would then need to document the requirements for ./start, which would be something along the lines of:

call exec with all the params passed in to you as args

So if your start script is in bash, your last line would be exec $@ again, while if it is python it would be different, etc.

Would love a PR, @meffij!

ping on this issue as a few people brought up a use-case @ the binder/jupyterhub talk here in Paris today:

many folks want to decouple the "content" of the repository from the "environment" needed to run that content (e.g. they want to be able to have notebooks live online independently of a Binder repo, and use the repo _just_ to define the environment needed. Then they could update notebooks without needing to re-build the Binder image each time. This could be accomplished with a script such as this one by using gitpull or something like this to pull in content after the server starts.

I ran into a use case for a custom launch script. In my case, I want to take an environment variable (JUPYTER_IMAGE_SPEC) and update a configuration template that ships with my repo. A simple sed/search-and-replace script is all I need but I need the full jupyter environment first.

I think this PR is firmly in the territory of "the project is 馃憤 on seeing this happen, it's just a question of somebody having the time to submit a PR!"

Was this page helpful?
0 / 5 - 0 ratings

Related issues

betatim picture betatim  路  6Comments

sje30 picture sje30  路  3Comments

betatim picture betatim  路  6Comments

NHDaly picture NHDaly  路  6Comments

Morisset picture Morisset  路  5Comments