[Debian-pan-maintainers] Napari

Thu Apr 7 12:38:03 BST 2022

On Tue, 22 Mar 2022 at 12:51, Emmanuel FARHI
<emmanuel.farhi at synchrotron-soleil.fr> wrote:
>
> Hi Neil,
>
> That's good to look into Napari, which I understand represents quite an involvement.
>
> Before you start this process, which will come in time, I suggest you first look into:
>
...
> reconsider the status of 'aprpes','mpes', and 'bokeh' and even perhaps 'orange/quasar' now that many dependency packages have been pushed on our side. Perhaps what seemed too much an effort a year ago now looks within reach.

My experience with packaging Javascript is approximately zero, but
I've used a tutorial from the Debian Javascript Team
(https://wiki.debian.org/Javascript/Tutorial) to at least quantify the
remaining JS work for bokeh (2.4.2 and 3.0.0dev5):

- 12 node packages remain to be uploaded. Of these, one is
particularly problematic - node-timezone.
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944398):

    This seems to embed tzdata, which is bad as it will mean more work
on supported
    releases as it's one more package to update whenever there are
timezone changes.
    It would be nice if tzdata provided a tzdata-source package that
this one could
    build-depend on, and with new tzdata releases we'd just need to
rebuild this one.

   Btw the upstream version and your package are still using tzdata
2018i which is
   outdated. If this gets in the archive you should commit to get it timely
   updated, not only in sid but also in (old)stable.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944398#10

As yet, there is no tzdata-source or equivalent package. It really is
a non-starter to think about handling an embedded tzdata in
node-timezone across all releases, so something else will need to be
sorted out. (This also raises a question whether bokeh would correctly
handle timezones when used from pip/npm if the underlying JS is using
out of date tzdata. Fixing this is certainly beyond my packaging
abilities. It needs a person with extensive JS experience.

The JS for bokeh appears to already be split out into a node-bokehjs
upstream. The other node dependencies to package node-bokehjs for
Debian are:
MISSING:
bokehjs
 └── canvas2svg (1.0.21)
 └── flatbush (3.3.1)
     └── flatqueue (1.2.1)
 └── gloo2 (0.0.1)
 └── hammerjs (2.0.8)
 └── numbro (1.6.2)
 └── proj4 (2.3.17)
     └── mgrs (0.0.3)
 └── slickgrid (2.3.23)
     └── @types/slickgrid (2.1.32)
 └── underscore.template (0.1.7)

https://www.npmjs.com/package/canvas2svg
https://www.npmjs.com/package/flatqueue
https://www.npmjs.com/package/flatbush
https://www.npmjs.com/package/@bokeh/gloo2 (This one looks specific to bokeh)
https://www.npmjs.com/package/hammerjs
https://www.npmjs.com/package/mgrs
https://www.npmjs.com/package/proj4
https://www.npmjs.com/package/@types/slickgrid
https://www.npmjs.com/package/slickgrid
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838985 but no
activity on that since 2016.)
https://www.npmjs.com/package/underscore.template

This is only the current state - the JS ecosystem can often add new
dependencies, so packaging these 12 now is no guarantee that future
versions of bokeh JS would be supportable.

>From the perspective of ARPES and MPES, would a better route be to
*only* package the Python elements of bokeh? There is only 1 Python
dependency not yet packaged for Debian (xyzservices) and it looks
straightforward to package from an initial glance. This might need
some intrusive patches to bokeh but should allow ARPES and MPES to be
packaged.

Neil.

>
> We are in the process at SOLEIL to 'secure' our funding over a few years for the packaging work you perform. So I'm quite confident the Napari stack can be pushed in time for Debian 12, even though it may require about a month from now to actually be able for us to buy more hours. No doubt we shall have fresh meat for you to eat.
>
> Cheers, Emmanuel.
>
> Le 22/03/2022 à 13:28, Neil Williams a écrit :
>
> Hi Emmanuel,
>
> XrayLarch is still progressing - waiting for the FEFF support to clear NEW.
> BioXtas-RAW has now also been added to NEW.
>
> In the README, one of the next packages is Napari, multi-dimensional
> image viewer for Python.
>
> https://github.com/napari/napari
>
> I've had a quick look at Napari and there is a bit of a chain in the
> dependencies that will also need to be packaged:
>
> Napari needs the following NEW packages:
> - cachey
> - magicgui
> - napari-plugin-engine
> - superqt
> - npe2
> - napari-console
> - napari-svg
>
> In turn, magicgui and npe2 require psygnal. It is possible that there
> are some others, depending on what is required to get some kind of
> testing running on some of these packages.
>
> I just wanted to make sure you were aware because getting Napari into
> Debian is going to mean first packaging this entire chain. This will
> use up all the remaining hours and likely spill over into another
> chunk of time. If the work starts soon then the chain can probably
> clear NEW in time for napari to be available in the next stable
> release, Debian 12 bookworm.
>
> Before I start on napari, are you OK with using your current hours in this way?
>
> --
> / ___|__/\_| |   | ____|_ _| |      FARHI Emmanuel
> \___ \\    | |   |  _|  | || |      Div Exp/Data Reduction and Analysis Team
>  ___) /_  _| |___| |___ | || |___   Tel : +33 (1) 69 35 96 04
> |____/  \/ |_____|_____|___|_____|  Saint-Aubin BP 48 - 91192 GIF/YVETTE CEDEX
>                        SYNCHROTRON  http://www.synchrotron-soleil.fr