JupyterHub and BinderHub Team Meeting - November

Welcome to the Team Meeting

Hello!

If you are joining the team video meeting, sign in below so we know who was here. Roll call:

  • Tim / Binder / @betatim

  • Alex / Treebeard / @alex-treebeard (just want to learn/observe)

  • Sarah / Alan Turing Institute / @sgibson91

  • Simon / OME, University of Dundee / @manics

  • David / Software Heritage / @douardda

  • Mridul / GESIS / @MridulS

  • Rollin / NERSC / @rcthomas

  • Min / Simula / @minrk

  • Richard / Aalto University / @rkdarst

Quick updates

60 second updates on things you have been up to, questions you have, or developments you think people should know about. Please add yourself, and if you do not have an update to share, you can pass.

Reports and celebrations

This is a place to make announcements (without a need for discussion). This is also a great place to give shout-outs to contributors! We’ll read through these at the beginning of the meeting.

  • Erik is a force of nature when it comes to switching to GitHub Actions!

Agenda items

Let’s collect all potential agenda items here before the start of the meeting. We will then attempt to create a coherent agenda that fits in the 60m meeting slot. If there are similar items try and group them together.

  • Tim [10minutes]: Use calver and cron job to release repo2docker once a month

    • what do people think of tagging a release of repo2docker every month using a cron job in github actions? Using something like calver (for example v2020-11 for the November 2020 release) to assign a version to it. Using a cron job feels a bit “radical” but it would solve demand from the community for regular releases and automate our current recommendation of “you should be able to use master”.

    • People want to be able to pip install jupyter-repo2docker so we need to release to PyPI, not just tag in GitHub.

    • If there was a way to make it easy for people to “install master” while doing pip install Tim would favour that but no one knows how to do that.

    • dask calver discussion: https://github.com/dask/community/issues/100

    • Should we also do this for BinderHub?

      • potentially more tricky because we need to fit into SemVer syntax for our helm chart versions

      • It is not required that the helm chart version matches the software version. Tim’s impression is that most helm charts actively try to make the chart and software version “very different” to avoid the impression that they are related.

      • we already publish a helm chart on every merge into master

      • Tim would not change anything about BinderHub for now.

        • we have some work to do just to restore the old behaviour of publishing a chart for every master commit because Travis is out of business.

        • Simon: I agree, repo2docker is much more widely installed than BinderHub, so let’s focus on that first and deal with BinderHub later

    • Issues asking for releases:

    • Issues discussing ideas for automating/procedure:

    • Sarah: There is a GitHub Action for publishing to PyPI too! https://github.com/marketplace/actions/pypi-publish

    • Tim: no opposition, let’s pick a CalVer version without discussing it too long because it seems to turn into a never ending discussion

  • Simon [5 mins]: Planning to transfer https://github.com/manics/action-k3s-helm/ to jupyterhub organisation

  • FYI new additions to binder

    • Mercurial provider (BinderHub PR, already added to repo2docker)

    • Software Heritage Identifiers (SWHID) (Proposed addition)

      • Who uses SWH and how?: It’s an open archive so there are many anonymous users. Online journals are beginning to ask submitters to make sure the software is present in SWH archive. HAL (French repo for scientific open-access papers) -> largest percentage of users come from this use case.

  • Tim: what about python kubernetes v12 API client?

  • should henchbot use the “gh-pages published as a webpage” version of the helm charts repo instead of raw github

    • maybe run henchbot less often?

    • only consider a “version” ready when it is at least 5min old