[Forwarded to debian-science, list address in previous mail was wrong but I think it was meant to be sent here]
> I would like to know if you are planing to package > jupyterhub/jupterlab/binder for Debian Buster> > It would be great to communicate about your plan for he jupyter eco-system. > This way peoples, will know what is going one on the jupter front and can > help. > It seems that your are the guyes whom do the job nowadays , this is why I > contact you Sorry for the delay in responding. In principle, I would be interested in packaging a number of additional jupyter-related packages, including jupyterhub. However, for family reasons my available time is currently minimal, and at best I'll be able to keep existing packages updated for at least the next few months. Depending on circumstances I might be able to work on it more later this year. Things that need updating: * ipython. The current package is pinned to ipython 5.x (the last series supporting python 2.7). The source package should be split so the python 2.7 version can be kept on the current branch and the python 3 version updated to the 6.x series. * jupyter-notebook. It currently has some functionality not fully working (the shortcut editor) due to issues around unpackaged javascript libraries (preact). The current discussion on d-devel around how to handle vendored dependencies in complex packages might be relevant - if there is slightly more tolerance of embedded JS libraries, this will be easier to maintain - otherwise every update comes with the risk of new, unpackaged JS dependencies. * ipywidgets. There are big changes to the JS dependencies for upgrading 6.x -> 7.x; the set of new dependencies largely intersects that needed to package jupyterlab. Possibly interesting new packages: * jupyterlab (lots of JS dependencies) * jupyterhub (needs node-configurable-http-proxy, some thought around default config/integration) * out-of-tree jupyterhub authenticators/spawners (eg, oauthauthenticator, systemdspawner) * binderhub * nbdime (including a web interface, but packaging just the git extension looks fairly simple) Adding more supported languages to jupyter: * irkernel (I originally filed ITPs for this and depends, but they've never managed to get it on CRAN and I've been unsure whether to proceed as eg, `r-other-irkernel` or wait and see if they could get it included; I have experimental packaging ready for this, but there is now another R kernel `juniper` which is on CRAN, but has some C++ dependencies) * ijulia (the other original part of the julia+python+R => jupyter equation; I have experimental packaging for this, but it would require providing system copies of a number of julia libs, and the debian julia package is now quite out of date due to libgit2/openssl issues) * ijavascript (requires a couple of node dependencies, but should be fairly straight forward; I have experimental packages for this) * ihaskell (I managed to get this to build, but had difficulties getting it to work - would need some input from a haskell expert) * iruby - looks fairly simple to package, but looks like it isn't getting updated for a while * octave - requires metakernel and octave-kernel (which are python, should be fairly simple, I have experimental packages for this). I'll try and push what experimental packaging I have to my salsa namespace: https://salsa.debian.org/chronitis-guest when I get a chance It would perhaps be worth having an explicit team for jupyter-related packages; they mostly live in DPMT at the moment. > > thanks for considering. > > Frederic. > > >
