Le lundi 12 mars 2018 à 20:54 +0100, Gordon Ball a écrit : > [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.
+1 > 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. Shall we introduce src:ipython5 producing the ipython stack for Python 2 and keep src:ipython for version 6.x onwards and only build the stack for Python 3? > * 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. Ack. > * 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. Ack. > Possibly interesting new packages: > > * jupyterlab (lots of JS dependencies) I had a look at that and the phosphorejs JS toolkit alone will be quite an effort from my first look at it. > * 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. I wonder what we would gain from a new packaging team, versus using the Debian Science Team umbrella? Ghis
