# GitHub Actions + Binder

**URL:** <https://discourse.jupyter.org/t/github-actions-binder/2651>\
**Category:** Binder\
**Tags:** community, how-to\
**Created:** [November 10, 2019, 7:32pm UTC](https://discourse.jupyter.org/t/github-actions-binder/2651 "2019-11-10T19:32:48Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![psychemedia](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/psychemedia/32/24_2.png) [@psychemedia](https://discourse.jupyter.org/u/psychemedia)\
**Post date:** [November 12, 2019, 9:27am UTC](https://discourse.jupyter.org/t/github-actions-binder/2651/6 "2019-11-12T09:27:13Z")

</div>

@hamel

There was some early thinking on dependency metadata fields in this Jupyter notebook thread: [https://github.com/jupyter/nbformat/pull/60](https://github.com/jupyter/nbformat/pull/60)

I’m sure I’ve seen some other similar treatments over last few months but can’t find them offhand… Hmm… [Ah, this is maybe one of them: [`ipydeps`](https://github.com/nbgallery/ipydeps)]

One way round the hugely bloated kernel option is to provide multiple kernels with slightly different dependencies in each (although that can still result in a large image). [JupyterWith](https://www.tweag.io/posts/2019-02-28-jupyter-with.html) takes that approach, I think?

See also a recent post on this forum which considers a “proxy kernel” that mediates specific kernel requirements: [Guix-Jupyter: Towards self-contained, reproducible notebooks](https://discourse.jupyter.org/t/guix-jupyter-towards-self-contained-reproducible-notebooks/2379)

By the by, the [repo2docker github action](https://github.com/machine-learning-apps/repo2docker-action) to autobuild a docker image and push it to DockerHub also reminds me of this CircleCI recipe to do a similar thing: [binder-examples/continuous-build](https://github.com/binder-examples/continuous-build/)

---

_[View the full topic](https://discourse.jupyter.org/t/github-actions-binder/2651)._