In the long run, it would probably help you to better understand the tech behind what you are seeing happen. Otherwise, you’ll just inch along & then be back at square one with each new session you launch.
Binder uses configuration files to specify the environment that launches in sessions spawned from specific repositories and archives. You just get a default, very basic Python back environment if you launch Binder referring to a repository without such configuration files.
For example, this example repository contains a file called
requirements.txt. That is the critical file for specifying the packages needed to be installed when that session spins up. That page explains it uses
pip to install those particular packages. This is important to understand. If you need a dependency that cannot be strictly
pip installed then you need a different type of configuration file or at least an additional one. While the
requirements.txt example is one of most straightforward examples. You’d want to check out the other example binders and eventually get a sense of what configuration files can do perform what installation tasks happen when the Docker container is made that will be used to launch your active session. (Note the example pins a lot of packages in that
requirements example. While that is great if you need this to run exactly as it was at that time, it isn’t what what you’ll want to do when getting started. For example, to get started, it is always best to just list
pandas in your
requirements.txt file and see if that allows you to do what you need to do. This is because you’ll have to troubleshoot much less if you aren’t pinning and so for the starting Binder user this is the path of least resistance.)
Now, from the nbviewer page you link, if instead of launching a binder session, if you press the button to go to the Github repo you’ll see the associated repo is rather old and doesn’t have any configuration files or reference Binder. This is a long way of saying the developers didn’t set it up to do what you’ve tried to do. This makes sense as Binder was just starting up back then.
However, because you now understand what is needed by Binder, you now have a few options. You can find a repository that already has configuration files to do what you want to do and then you can launch sessions from there and then open & run the notebooks in those sessions. Or you can fork the repository and set it up yourself.
Some examples that already install Keras (I have not tried these individually):
That above is how you’d ideally work so you’d be able to come back later. However, once in a while, especially during development you want to run code that needs a package you didn’t install yet. If it is something straightforward to install, such as
pandas, you can just install pandas within the ephemeral session. To do that use the newer pip magic for the best experience. In a Jupyter notebook cell to install pandas run the following, if the module isn’t there already:
%pip install pandas
Likewise if the package is straightforward to install with conda, you can do the following:
%conda install <package_name>
For what is behind the
%conda magic, see bottom couple of paragraphs here where it begins ‘Alternatively, you can put the following lines …’.