You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
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
The text was updated successfully, but these errors were encountered:
Next steps for improving the binder experience:
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:
! pip install ...
commandupdating 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.
The text was updated successfully, but these errors were encountered: