I'm putting together a series of binder executed repos that are composed of particular components with their own dependencies.
At one level, this might be a quite simple dependency, such as a Python package installed by pip
that requires a particular Linux package to be installed via apt.txt
first.
Or it might be more elaborate - for example a pseudo collection of packages to "implement" a particular sort of functionality, such as a range of tools too handle map display.
To try to ease the pain of remembering what Linux package is a pre-requisite of which python package, it might be useful if we could bundle the requirements as pseudo/self-named collections.
For example, I have three "topics" in the following build (the build may not be sensible!): some map handling stuff (maps), some astronomical stuff (astro-stuff) and some notebook presentation stuff (presentation).
maps:
- apt
- libproj-dev
- libgeos-dev
- conda
- channels
- conda-forge
- dependencies
- python
- matplotlib
- basemap
- pip
- folium
astro-stuff:
- conda
- channels
- astropy
- dependencies
- python
- astropy
presentation:
- pip:
- jupyter_contrib_nbextensions
- RISE
- jupyter-wysiwyg
- postBuild
- jupyter contrib nbextension install --user
- jupyter nbextension enable widgetsnbextension --py --user
- jupyter nbextension enable python-markdown/main --py --user
- jupyter-nbextension install rise --py --user
- jupyter-nbextension enable rise --py --user
- jupyter-nbextension install jupyter_wysiwyg --py --user
- jupyter nbextension enable jupyter_wysiwyg --py --user
What I imagine happening is that binder.yaml
parser could take such a file and generate separate apt.txt
, environment.yml
or requirements.txt
, and postBuild
files representing the set intersection of the various build components. (I guess there could be version conflicts in there.)
For the user, it would mean they have just a single config file to worry about, plus they can reuse components that represent complex builds (the Linux package you always forget is a dependency, the post-build enabling of an extension, etc).
Looking at the above file, I could also imagine further levels of nesting, eg in terms of jupyter-nbextension install
or jupyter-nbextension enable
, though adding too many hard-wired paths to particular sorts of operation may reduce the overall utility of a binder.yaml
parser?