[Debian-science-sagemath] jupyter-notebook/widgets

[Gordon Ball]

On 08/11/16 12:21, Ximin Luo wrote:
> Ximin Luo:
>> Gordon Ball:
>>> On 07/11/16 17:06, Ximin Luo wrote:
>>>> Gordon Ball:
>>>>> I have spent quite a few hours trying to work out why it doesn't work
>>>>> with jquery-ui-1.12, without success. It isn't due to the debian
>>>>> packaging of jqueryui (same issues just updating the npm package and
>>>>> trying to rebuild). Nothing in the migration guide for 1.10 -> 1.11 or
>>>>> 1.11 -> 1.12 obviously seems to be a reason, but I think it is something
>>>>> to do with the way jupyter handles module loading.
>>>>>
>>>>> Unfortunately I don't have a deep enough knowledge of requirejs and
>>>>> other hacks needed for big javascript projects to know how to dissect this.
>>>>>
>>>>
>>>> Hey Gordon,
>>>>
>>>> I messed around quite a lot with requirejs in a previous job. I might be able to help. Could you talk about this issue in some more detail?
>>>>
>>>> X
>>>>
>>>
>>> I *think* I have been able to patch the notebook issue, but perhaps you
>>> can have a look at the patch and see if it makes sense [1].
>>>
>>> The issue appears to have been that jquery-ui added an AMD loader
>>> wrapper in 1.12, and the existing configuration assumed otherwise.
>>>
>>> The relevant files are:
>>>  * notebook/templates/page.html (notebook page template, including
>>> browser-side requirejs config)
>>>  * tools/build-main.js (requirejs configuration used to build the
>>> main.min.js amalgamation at build time)
>>>  * notebook/static/notebook/js/{pager,outputarea}.js (page components
>>> importing jquery-ui)
>>>
>>> [1]:
>>> https://anonscm.debian.org/git/python-modules/packages/jupyter-notebook.git/tree/debian/patches/0004-jquery-ui-1.12-compatibility-changes.patch
>>>
>>> So, hopefully jupyter-notebook is ready again, less any more surprise
>>> libjs-* transitions.
>>>
>>
>> Hey Gordon, that makes sense yes.
>>
>> Holy shit I hate javascript. It took me a while to make sense of it, I was looking at the libjs-jquery-ui source package first which is very misleading because it doesn't corresponding to the binary package very well. But by reading /usr/share/javascript/jquery-ui/jquery-ui.js you can see that indeed when you load jquery-ui as an AMD module, it depends on jquery then it edits the $ jQuery object but returns nothing - which is why you need those extra explicit dependencies on jquery in your patch, to get the $ object, and the __ object you get when loading "jquery-ui" would be undefined (if I am reading the aforementioned file correctly).
>>
>> Basically, they have no idea WTF they are doing or what good software engineering patterns are.
>>
>> In other words, the top 2 Google results for "jquery-ui amd loader"
>>
>> https://stackoverflow.com/questions/12113172/how-do-i-use-jquery-ui-with-requirejs -- wrong
>> https://learn.jquery.com/jquery-ui/environments/amd/ -- assumes a different tree structure
>>
>> Holy shit I hate javascript.
>>
> 
> BTW, I guess the use of requirejs means that effectively the binary package is "statically linked" to its dependencies? If so, you should document that in README.Debian -- something like "this package embeds some of its build dependencies (X, Y, Z) and should be rebuilt when those are updated".
> 
> I remember I had to add nasty hacks to make r.js build-products "dynamically link" to their dependent at run-time; it's probably not worth the effort doing it here.
> 
> The reproducible-builds / dpkg work on .buildinfo files will record the exact versions of the build-dependencies used to produce a particular binary package, so you don't have to do any extra work for this. (I think dpkg >= 1.18.11 has it.)
> 
> X
> 

It appears to be partially statically linked. Some of the javascript
sources are inlined (like jquery-ui.min.js), and some (like es6-promise,
requirejs, mathjax) are still loaded directly.

Admittedly, I hadn't fully appreciated how much of the JS gets inlined
into their main.min.js before this issue. The install manifest generated
by setup.py still includes files like jquery-ui.min.js, even though
they're apparently never accessed after build. Plus, the associated CSS
(eg, for jquery-ui) is still loaded directly.

I think this probably means that Built-Using headers should be generated
for the relevant packages, at least.