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.
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.
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?
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 github.com/binder-examples or link to them. Depending on what people prefer. Or even from the landing page on mybinder.org. (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: