On Tue, Sep 21, 2021 at 2:23 PM Gordon Ball <gor...@chronitis.net> wrote: > Indeed. qa.d.o betrays me.
you cant hide the good work :) > The answer to this was delayed because I considered several times what > it should actually be. thanks for your thorough explanation! > The _python_ side of ipywidgets has never been a problem, but the > JS/browser side has grown in complexity considerably in recent years, > and shows little sign of slowing down. > > The debian javascript situation has improved somewhat - it was possible > to significantly simplify the labyrinthine custom build infinity0 did > for ipywidgets 6 in 6.0.0-8 to mostly use logic from pkg-js-tools, and > having recent versions of eg, webpack helps a lot. I don't think however > there is really a useful way of providing "only" the python side of > ipywidgets in debian. It's already a concern that needing to unvendor > javascript and hack build processes results in a substandard experience > in eg, jupyter-notebook, and I don't think it's viable to ship > ipywidgets unless we can get something resembling full functionality. > > The javascript side is blocked on jupyterlab (#934258). I know jpuydt > has done some work on it in the past, but I don't know the current > state. Some other signficant building blocks like lumino (ex-phosphorjs) > are now packaged. > > It might be possible to vendor only the needed bits of jupyterlab, as > was recently necessary in jupyter-notebook (CVE fix requiring multiple > new dependencies), but I think that illustrates the issue. While the > python side of jupyter proves tractable, the web application side is a > large, fast moving target which I have concerns about our ability to > really keep up and provide a good user experience. is there something (at least on the python side) that we can do to help you out in upgrading ipywidgets? or asking for help to the javascript team a viable option? would you think it's appropriate to evaluate to vendor the javascript dependencies? IIRC pip considered doing so (not sure if it was actually done), and notably kubernetes starting doing that, and that's been grought up to the TC and that has not been overruled, so when the balance between maintenance cost vs split dependencies into separate packages is vastly in favor of the former (as it appears in the ipywidgets case) vendored is somehow tolerated > I will certainly _attempt_ to get ipywidgets up to date during this > cycle. But given missing dependencies and the time likely to be > required, I don't think I can guarantee it. If it cannot be updated in a > reasonable period of time, I think the question of whether it is better > to drop it might arise. I appreciate there are dependencies, although I > think most of them are ultimately optional. there are some rather important modules in the rev dep list: Checking reverse dependencies... # Broken Depends: jupyter-sphinx: python3-jupyter-sphinx q2-demux: q2-demux q2-feature-table: q2-feature-table sagemath: sagemath-jupyter # Broken Build-Depends: jupyter-sphinx: python3-ipywidgets matplotlib: python3-ipywidgets nbsphinx: python3-ipywidgets pandas: python3-ipywidgets plotly: python3-ipywidgets sagemath: python3-ipywidgets (>= 6.0.0) Cheers, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
