-
Notifications
You must be signed in to change notification settings - Fork 16
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
Reduce mybinder startup time #14
Comments
The split of content and environment is started:
|
Trying out
|
This is the one i created via filling out the form at
|
In the OPENSENSE_sandbox_outsource_environment fork has the environment removed and the README.md adapted points to the binder url using the OPENSENSE_sandbox_environment. |
To me it looks as if we just have to adjust the URL template here With this URL will always reference the env defined in the main branch of the sandbox env repo. That means that, if somebody has to adjust the env, he/she has to do an updated of the env repo first. The bot that adds the binder button should add a note that users have to take care of env updates in the env repo if they need an env update. In such a case, I would suggest to create a branch or PR of the env repo, do the update of the env there, and then manually adjust the binder URL to test if binder can build the env and if everything runs correctly. |
We are close and there is a pull request for it but the readme.md url of the binder button is not loading the notebook |
@georges-schutz This is the full path that they use in their README
|
maybe like this
(created with nbgitpuller web form) |
The pull request PR#31 is ready to be merged back to the upstream. |
With #31 now being merge we have the problem that the submodules are not recursively cloned. nbgitpuller might support that, see jupyterhub/nbgitpuller#123, but I do not (yet) know why. |
The binder re-builds itself after every commit whether the environment.yml is changed or not. This takes a long time and will in future, with even more dependencies even be slower. There are several ways to reduce the startup time and the most promising one from this jupyter discourse page are presented here which splits up the environment and the content in two repositories:
Use two repositories: one for the environment, one for your content - many people change their content much more often than they change the environment needed for it. However, Binder will re-build the environment for any changes to a repository. A hack to get around this is to define an “environment repository” that Binder builds, and use a hook to pull in new content at launch from a “content repository”. This means that your “environment repository” changes less-often, which should result in fewer new builds and reduced launch times. See the instructions in this post to get started.
Use the nbgitpuller.link page to automate separate content/environment repos. The above step can be (mostly) automated by using nbgitpuller.link. This is a little web form that generates JupyterHub links for you. To quickly create a link for content/environment repositories, go here:
nbgitpuller.link?tab=binder
and fill out the form.
You can also pre-populate the form with some fields. For example:
nbgitpuller.link/?tab=binder&repo=https://github.com/binder-examples/requirements
will use the binder-examples repository as the “environment” repo.
The steps towards the use of
nbgitpuller
should be tracked by this issue.The text was updated successfully, but these errors were encountered: