Feature idea: extension to simplify Binder publishing (lab>git>binder)

Similar to the RStudio Server publishing functionality, I’d like to advocate for a publish-to-Binder feature within default JupyterLab UI. There’s an entire scientific community waiting to blossom to it’s full potential here; Twitter meets arxiv w graph-based citation NLP. The network effect (quadratic multiplier) of a scientific community is how you beat VS Code & Google Colab.

Key to success would be reducing the hassle of publishing to a version control repo. Maybe the solution is using a github token to make it dead simple to publish a nb as a gist? It has to be frictionless (< 5 clicks and a name/ tag text field).

I encountered this problem recently when I wanted to rapidly publish the output of the plotly charts in my nb. I decided to skip the publish process and just exported nb to html and uploaded to s3. I also didn’t want to invest time in specifying dependencies.


Validation for this workflow:

  • Deep Learning for Coders with fastai & PyTorch (JHoward, p.84); using Voila apps for inference UI.

Shoutout to @ellisonbg for highlighting the “share knowledge” theme in the first place.

@choldgraf

1 Like

Sounds like a cool idea! It could be developed as a JupyterLab plugin to begin with. Is this something you’ve already started work on?

Would you expect people to already have a GitHub account, or do you envisage this being used on private Binderhubs where everyone is trusted and the Binderhub admin could setup a single GitHub token for everyone?

1 Like

I have not, but it should just be a few API calls, so I’ll look into it this week.

To start it would just be individual githubs to public binders, but yeah, good idea, I didn’t even think about the hubs.

1 Like

I like the idea!

One thing I am unclear about: is this about making it easy to publish from my laptop/desktop computer or from a running mybinder.org session?

Asking because for the “publish from a BinderHub session” there are a few issues on GitHub discussing ideas and their trade-offs. In particular the problem of “please don’t put any private credentials in your binder”. If that is what you want to target its worth digging through those (I can try and find them).

1 Like

Clarifying scenario: My name is Henrietta. I work at a biotech company. I pip install jupyterlab on my laptop and write a notebook. I can use a feature in JupyterLab to publish it to mybinder.org

Yes, I’ll read anything you share.

1 Like

In general I think this is a really cool idea. I agree it’ll benefit the community to have more fluid ways to connect these services together.

Two quick thoughts:

  1. Binder requires an environment. I think that for this to work we’d also need some way to package an environment with the notebook. Check out this issue for some context, it’d be great to see progress there: Add a JupyterNotebook buildpack and contentprovider · Issue #825 · jupyterhub/repo2docker · GitHub
  2. Another thing to consider is yuvi’s https://ipynb.pub, which wouldn’t be interactive but could support this almost already, it’d just be the need for a lab extension.

@choldgraf metadata would be one way to do it, but a few birds could be killed with one stone by having a gui form in the extension that helps the user define the environment. Most of it can be scraped with import os, platform

Does my notebook need these optional things:

  • Specific version of python.

    • Dropdown of #.#.# versions.
      • Default to platform.python_version()
      • Fetch Docker image via url for that Python version.
    • Skip over the weird scenarios like Python including/ excluding optional zlib for now.
  • Specific versions of packages.

    • Text box for path.
      • Default to pip freeze or conda list
        • if ('conda' in sys.version) or ('Continuum' in sys.version)
  • Specific OS.

    • Default to os.name or platform.version()
    • E.g. multiprocessing works differently on Windows.
  • Other Files.

    • [Do most people use raw.githubusercontent.com urls for this?]
    • Data Files
      • Text boxes for paths.
        • Default to everything w csv, parquet, hdf5 file extensions.
    • .py scripts

I think you’d need UI around it whether there were a metadata environment standard in notebooks or not (IMO editing the notebook metadata directly is pretty painful). But agreed you could collapse a few configurations down to some simplified UI choices