Bug#801366: prototype
On 20/09/16 07:03, Julien Puydt wrote:
> Hi,
>
> On 19/09/2016 22:49, Gordon Ball wrote:
>> I have put together a more-or-less working jupyter-notebook package [1].
>> This only requires one as-yet-unpackaged dependency:
>> libjs-jquery-typeahead [2]. Everything else can be satisfied from
>> unstable, although a couple of dependencies are technically outdated:
>>
>> codemirror (>= 5.8, only 5.4 available),
>> term.js (>= 0.0.7, only 0.0.4 available)
>> jquery (>= 2.0, 1.12 available - but I think this is equivalent except
>> version 2 removes shims for old browsers)
>
> Looks good.
>
>> The only messy part is google-caja, the upstream for which appears to be
>> a jupyter-created nodejs repo containing itself the static output of the
>> upstream caja project, which looks like a nightmare to package. Since
>> the generated output is non-minified, readable code and includes a
>> license statement I propose to include it as-is.
>
> Last time I had a look, that was a single file. But if it's generated,
> I'm not sure we can include it as-is -- at least outside of experimental.
The file in the jupyter tarball comes from [3].
That repo appears to be set up by the jupyter team to provide a
bower-installable version of caja.
The actual `html-css-sanitizer-bundle.js` appears to be a concat of
(actual, non-generated) javascript source and json files containing
lists of HTML/CSS entities (from paths
src/google/caja/{plugin,lang/css,lang/html} in [4]). I think it's at
least arguable that it can be regarded as source (the individual files
could be included as `missing-source` if necessary).
[3]: https://github.com/minrk/google-caja-browser
[4]: https://github.com/google/caja
>
>> The upstream tarball is DFSG'd removing all the web components.
>
> Good.
>
>> The resulting package appears to work (tested: markdown, simple python,
>> matplotlib output, opening the builtin terminal).
>
> Excellent.
>
>> The package is only built for python3 - I originally tried to build py2
>> and py3 support with a common data package, but since this is
>> effectively an application and you can still run the python2 kernel
>> there seems little point packaging a python2 version and adding extra
>> complexity.
>
> Agreed.
>
>> The package currently only requires the javascript packages at
>> build-time, and copies the relevant files into the binary package. It
>> would be possible to symlink the files on install as well, but I suspect
>> it would be easier to freeze the set at build (should probably add
>> built-using headers).
>
> I think symlinking will be needed to get outside of experimental.
There is precedent in main for this approach (using libjs* at build time
but embedding the result) - see, eg, syncthing. Symlinking would save
some space (and can be done, although it would be a pain), but given the
lack of API or even layout guarantees for js upstreams I'm concerned
that creates a vector for breakage - since jupyter uses a different
directory layout for some of the js packages than the libjs version it
is necessary to symlink individual files rather than directories.
An autopkgtest could check the symlinks remain unbroken.
>
> That sounds wonderful : congrats for your work!
>
> Snark on #debian-python
Next steps? Move to d-python repo, ITP for jquery-typeahead and then try
and upload to experimental?
Reply to: