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.
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?
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).
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
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.
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
