Pondering this a bit more eg in context of this repo which is gitpulled into this Binder build (discussion), I wonder…
Github conventionally uses the gh-pages
branch as a “reserved” branch for constructing Github Pages docs related to a particular repo.
The binder/
directory in a repo can be used to partition Binder build requirements in a repo, but there are a couple of problems associated with this:
- a maintainer may not want to have the
binder/
directory cluttering their package repo; - any updates to the repo will force a rebuild of the Binder image next time the repo is run on a particular Binder node. (With Binder federation, if there are N hosts in the federation, after updating a repo, is it possible that my next N attempts to run the repo on MyBinder may require a rebuild if I am directed to a different host each time?)
If by convention something like a binder-build
branch was used to contain the build requirements for a repo, then the process for calling a build (by default) could be simplified.
Eg rather than having something like:
we would have something like:
which could simplify to something that defaults to a build from binder-build
branch (the “build” branch) and nbgitpull
from master
(the “content” branch):
https://mybinder.org/v2/gh/colinleach/astro-Jupyter?binder-build=True
Complications could be added to support changing the build branch, the nbgitpull
branch, the commit/ID of a particular build, etc?
It might overly complicate things further, but I could also imagine:
- automatically injecting
nbgitpuller
into the Binder image and enabling it; - providing some sort of directive support so that if the content directory has a
setup.py
file the package from that content directory is installed.