How to understand dependency versions when deploying little binderhubs

Binder BinderHub
1

Hi there,

I’ve been happily experimenting and deploying small binderhubs through a largely manual process (but I’m getting closer to scripting this or attempting a tljh plugin).

One thing I struggle with the understanding how to clone a “release” of binderhub as there do not seem to be tagged releases, and requirements.txt files in the repo do not have pinned deps.

My question is - when setting out on on a local install like (without helm) what is the best way to understand a current working slice through the binderhub and jupyterhub dependencies?

For example, looking at the repo is seems like main is working towards a jupyterhub 4.0 based release, potentially with bugs and wrinkles to be ironed out.

So if I wanted to grab the right commit + dependencies for the latest working version that uses jupyterhub 3.x what would be the best way to do that? are pinned / working combinations / “releases” stamped somewhere other than the github releases (which seem like they are out of date)? or is there a way to glean this from the heml charts?

2

The requirements are “pinned” in the Helm chart container images, e.g.:

but in practice the dependencies should be fairly loose.

The coupling to JupyterHub is fairly relaxed too. BinderHub is tested with this version of the Z2JH chart (which comes with JupyterHub 4.0.1):

BinderHub/repo2docker effectively work on a rolling release basis where main should always be deployable, e.g. this is what mybinder.org deploys

1 Like