This would be similar to postBuild, but would be run at runtime, before execution of the actual notebook. This easily allows things such as:
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:
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)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:
exec ./start $@ (execute as command all parameters) as last lineexec $@ without the ./startWe 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!"
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
gitpullor something like this to pull in content after the server starts.