Bug#896460: Please package ipywidgets 7
5 years on, can we please start being more pragmatic about it and just ship the provided js files? Aren't other big packages like Firefox or Chromium also doing that? Or are they rebuilding all their js files from source? The Debian Javascript policy uses soft words like should and could for this: https://wiki.debian.org/Javascript/Policy This little package is basically holding sagemath and others hostage. It is the reason we have sagemath 9.5 in bookworm instead of 9.7 or 9.8. See #1010735. Best, Tobias On Sat, 21 Apr 2018 10:55:29 +0200 Tobias Hansen wrote: Source: ipywidgets Severity: wishlist Sagemath 8.2 uses ipywidgets 7 [1] and using version 6 causes about 80 doctests to fail. Best, Tobias [1] https://trac.sagemath.org/ticket/23177
Bug#896460: Please package ipywidgets 7
Source: ipywidgets Followup-For: Bug #896460 There are also 2nd order dependencies affected by this bug. Docs for scipy 1.7 use pydata-sphinx-theme, which depends on jupyter-sphinx. So the scipy upgrade is blocked.
Bug#896460: Please package ipywidgets 7
On Fri, Sep 24, 2021 at 12:02:50AM -0400, Sandro Tosi wrote: > On Tue, Sep 21, 2021 at 2:23 PM Gordon Ball 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'm quite willing where necessary to vendor unpackaged javascript libraries into the package - debian/missing-sources already contains several - but that isn't the main problem. The problem is that the javascript you get doing `pip install` really cannot be argued to be source - it's compiled from multiple javascript and typescript libraries, and it's well beyond any grey area around "maybe a minified copy of handwritten javascript is kind-of source". So it needs to be rebuilt, and that means getting a complex multi-stage source build to work. Just having the javascript dependencies packaged or vendored is only half the problem. > > > 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) > Looking at these, several appear to be wrong dependencies, and several are optional, unless I'm missing something from grepping their source: matplotlib/3.3.4-1: listed in requirements/doc/doc-requirements.txt, but not actually imported anywhere pandas/1.1.5+dfsg-2: listed in requirements-dev.txt, not actually imported anywhere plotly/4.14.3+dfsg-1: imported and used, but includes fallback if missing nbsphinx/0.8.0+ds-2: imported and used, but includes fallback if missing jupyter-sphinx/0.3.2-1: requires ipywidgets 7 (#950598) q2-demux/2020.11.1+dfsg-1, q2-feature-table/2021.8.0+dfsg-1 listed in ci/recipe/meta.yaml, but not actually imported anywhere sagemath/9.2-2: required, carries several patches for keeping ipywidgets 6 So I think we can probably clean up some unused dependencies there, and then it's a bit less DAG-critical. I will try and get it updated anyway. > > Cheers, > -- > Sandro "morph" Tosi > My
Bug#896460: Please package ipywidgets 7
On Tue, Sep 21, 2021 at 2:23 PM Gordon Ball 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
Bug#896460: Please package ipywidgets 7
Indeed. qa.d.o betrays me. The answer to this was delayed because I considered several times what it should actually be. 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. 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. Gordon On Sun, Sep 19, 2021 at 10:52:39PM -0400, Sandro Tosi wrote: > Hello Gordon, > you've been active uploading several packages of the ipython stack in > the last few days: can you provide an update regarding ipywidgets too? > thanks > > On Sun, Sep 12, 2021 at 12:01 PM Sandro Tosi wrote: > > > > Hello Gordon, > > > > On Sat, 21 Apr 2018 10:55:29 +0200 Tobias Hansen wrote: > > > Sagemath 8.2 uses ipywidgets 7 [1] and using version 6 causes about 80 > > > doctests to fail. > > > > do you have any plan to update ipywidgets to 7+ anytime soon? the > > upstream version currently in sid is severely outdated, being released > > more than 4 years ago! > > > > Several packages are requiring ipywidgets 7 and the lack of it in > > Debian is hold several maintainers back from updating their packages > > (I have 3 myself alone). > > > > This bug was open more than 3 years ago: please provide an update on a > > timeline for ipywidgets 7 for debian, so that we can plan accordingly. > > > > Thanks, > > Sandro > > > > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi
Bug#896460: Please package ipywidgets 7
Hello Gordon, you've been active uploading several packages of the ipython stack in the last few days: can you provide an update regarding ipywidgets too? thanks On Sun, Sep 12, 2021 at 12:01 PM Sandro Tosi wrote: > > Hello Gordon, > > On Sat, 21 Apr 2018 10:55:29 +0200 Tobias Hansen wrote: > > Sagemath 8.2 uses ipywidgets 7 [1] and using version 6 causes about 80 > > doctests to fail. > > do you have any plan to update ipywidgets to 7+ anytime soon? the > upstream version currently in sid is severely outdated, being released > more than 4 years ago! > > Several packages are requiring ipywidgets 7 and the lack of it in > Debian is hold several maintainers back from updating their packages > (I have 3 myself alone). > > This bug was open more than 3 years ago: please provide an update on a > timeline for ipywidgets 7 for debian, so that we can plan accordingly. > > Thanks, > Sandro -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#896460: Please package ipywidgets 7
Hello Gordon, On Sat, 21 Apr 2018 10:55:29 +0200 Tobias Hansen wrote: > Sagemath 8.2 uses ipywidgets 7 [1] and using version 6 causes about 80 > doctests to fail. do you have any plan to update ipywidgets to 7+ anytime soon? the upstream version currently in sid is severely outdated, being released more than 4 years ago! Several packages are requiring ipywidgets 7 and the lack of it in Debian is hold several maintainers back from updating their packages (I have 3 myself alone). This bug was open more than 3 years ago: please provide an update on a timeline for ipywidgets 7 for debian, so that we can plan accordingly. Thanks, Sandro
Bug#896460: Please package ipywidgets 7
Hi, There's any news about this? IPytree need ipywidgets>=7.5.0 Cheers, Emmanuel
Bug#896460: Please package ipywidgets 7
Hello, it appears that nbsphinx depends on ipywidgets 7 . Best wishes, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#896460: Please package ipywidgets 7
Source: ipywidgets Severity: wishlist Sagemath 8.2 uses ipywidgets 7 [1] and using version 6 causes about 80 doctests to fail. Best, Tobias [1] https://trac.sagemath.org/ticket/23177
