Binder template repositories

A few weeks ago GitHub announced that you can mark repositories as “template repositories”:

This makes it easier for people to use a repository as a starting point for a new repo. I think in the past a lot of people cloned a repo and then edited it when they wanted a template.

Related to An interactive Binder config file builder GUI I was thinking we could/should create some template repositories for use with repo2docker and BinderHubs.

Should we convert the example repos under or create dedicated ones?

I was thinking of creating three templates:

  • Python with pip: uses requirements.txt, gives advice on how to pin (or not) dependencies, has a empty postBuild containing a comment about what you can do here, runtime.txt to select Python version, badges to launch Jupyter notebook and Jupyter lab
  • Python with conda: uses environment.yml, mention how to select Python version, gives advice on how to pin (or not) dependencies, empty postBuild with comment, badges to launch Jupyter notebook and Jupyter lab
  • R with install.R: explain install.R, explain MRAN date and runtime.txt, empty postBuild with comment, badge that launches R Studio

These seem like the most frequent use cases for beginners/people discovering repo2docker.


1 Like

This could provide an easy way of defining customisable “Binder base boxes” - create a template repo that has packages typically required for a particular application area, and it can be used both as a Binder base box that supports content top-ups from other repos using nbgitpuller, but that can also serve as a basis for cloning and customisation / extension of the Binder config files?

One of the things I’m quite interested in is workflows around Jupytext, and the template repos could simplify that? eg here’s my first minimal attempt:

1 Like

I think this is a great idea - what do you think about two different layers of repositories.

One that would be for “base workflows” as Tim described above. It’d define basic environments, configuration files, etc…similar to what we’ve already got in binder-examples.

The second would be something more like “more opinionated” or “more specific” workflows, that would be for a particular challenge like “authoring” (that could include Jupytext and include a demonstration of the workflow that uses it) or “reproducibility” (that could include a nicely-version-tagged configuration file, show off how to mint a DOI, etc. This group would be more aspirational in nature and would evolve as more tools became available etc. Both groups of repositories would be meant to be demo’ed in Binder and templatized with GitHub for others to try.

Let’s do it. I think this is an opportunity for people to help out. Anyone can create one of the template repositories (pip, conda, R) I mentioned, a base binder (like Tony mentioned, kaggle binder, ouseful binder base) or a concrete, task specific one that Chris mentioned.

We can then host them on or link to them. Depending on what people prefer. Or even from the landing page on (Direct links to working examples/how to get started was a frequent ask in the binder user survey!)

Agreed - there are (at least) those two classes of box, maybe even three (or more?):

  • how to drive BinderHub through different sorts of config files;
  • opinionated boxes that set up a particular environment or workflow (eg authoring Jupyter Book w/ jupytext, setting up different nbgrader environments, setting up stencila)
  • opinionated boxes that can be used to quickstart a particular project in a given topic area (eg a scipystack build, an astronomy build, a text processing (nltk/spacy) build etc);

By the by, I think some templated recipes for how to run from repo2docker on the command line, showing how to mount various volumes etc, might also be useful for folk who want to run things locally using repo2docker but don’t really understand Docker/command line voodoo?

Also in the hinterland of templates, building blocks, and deployments:

I’m not sure if these pieces are part of the same jigsaw or different ones. Or maybe it doesn’t matter?

1 Like

I think the nbgitpuller pattern to separate image requirements from content (massively reduces rebuild requirements) is a great idea to start with.