Re: Fwd: Re: jupyter-hub debian package
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
Reply to: