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

Binder #3

Closed
7 of 12 tasks
edublancas opened this issue Aug 17, 2022 · 0 comments
Closed
7 of 12 tasks

Binder #3

edublancas opened this issue Aug 17, 2022 · 0 comments

Comments

@edublancas
Copy link
Contributor

edublancas commented Aug 17, 2022

Next steps for improving the binder experience:

  • Binder rebuilds the docker image whenever it detects a new commit in the repository. To fix this, we can create a separate repository that contains the environment. see this for details, and see this for an example - we don't need one binder env per project, we can just create one with all our packages
  • We need to replace the links in our repos so they use our binder deployment
  • Update core package so it logs relevant environment variables dealing with environment variables core#13
  • We should also think how to simplify the process for users that got excited after using some Binder example, so they start running things locally. Binder already adds a button to download notebooks, but the user must figure out what dependencies to install. See below for details
  • Adding binder links: we need up update the binder links to they point to our deployment, see below for details
  • Disallow building non-ploomber repositories
  • most people don't know what binder is, we should create a custom button
  • explore thebe. it might be a better alternative since users can run the examples without leaving the documentation website
  • Ask users to optionally enter email to get updates

from binder to local

Update: started k2s to do this

once a user gets excited about what they run on binder, we should help them get them started locally. it should be simple to download a notebook, install packages and run the same example locally so that they can adapt it to their needs.

I think the simplest way is to have two versions on the same notebook. the normal one and another one (which is what the user will download), whose first cell installs all packages to ensure that notebook runs. Even though installing packages within the notebook is not considered best practice, this is the simplest way, otherwise, users might end up installing it in the wrong place (e.g. in sagemaker the server and the notebook run on different instances).

ideally, this should only install what this specific notebook needs (and not the repository-wide requirements). we can use something like this

I imagine something like this:

  • User clicks a button to download the notebook with the cell with the ! pip install ... command
  • maybe: show how to upload to their JupyterLab by dropping it in their JupyterLab
  • They upload in their jupyterlab

updating binder links

we need to update the binder links across our repositories. This will vary depending on what are we using to generate the documentation.

  • ploomber/projects has some custom logic (perhaps we should move this to ploomber/core?)
  • ploomber/sklearn-evaluation has an automation (copy pasted from projects, we should consolidate)
  • ploomber/jupysql uses jupyter-book, we can easily configure this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant