We’ve recently launched a pilot with AGU NotebooksNow! that allows for notebook based publications that can be backed by a binder instance, so that readers can either jump to an instance of jupyter lab or execute notebook cells in place with MyST Markdown’s web stack.
As part of that we’ve developed an initial ContentProvider/RepoProvider combo to allow binder to launch from MECA (Manuscript Exchange Common Approach) bundles which contains JATS xml that scholarly folks enjoy, and the reproducible package needed to “run the article/paper” (this is just REES). At the end of the day it’s an opinionated zip file but one that people out there in publishing land are already using.
The code is here: GitHub - curvenote/meca4binder: Package with providers for BinderHub and repo2docker
This implementation is working well just now, the ContentProvider and RepoProviders are doing their things, and maybe could be improved in terms of how they are functioning but the integration with binderhub and repo2docker is “not great at all” as, as far as I know there are no integration (e.g. plugin) points for custom providers, and I’ve needed to duplicate some of the base provider code for this package to work and manually patch these in on deployment.
So thinking of where to take this next, here are some questions for the binderhub/mybinder contributor community:
- What would be the best way to improve the integration of these two classes to their host packages? i.e. so that they could plug into binderhub and repo2docker more easily?
- It would be awesome to add this provider in the mybinder.org default list of providers (which effectively means it gets bundled by default with binderhub & repo2docker?)
- are there things that would need to improve about the implementation for that to happen?
- should we just split up this repo and open PRs on binderhub & repo2docker to start that process/conversation?
- Feedback on the implementation itself is very welcome – is there anywhere where we’ve over-complicated things? this is the first repo/content provider pair we’ve done and we might have mis-interpreted the intent of parts of the interface for each class.
Cheers
Steve
