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

[Ximin Luo]

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

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git