Packaging mathjax and other javascript libraries

Packaging mathjax and other javascript libraries

[Arun Isaac]

A couple of days back, I submitted a patch packaging mathjax. My
conversations with Brendan there raised some more general questions. So,
I'm posting here for wider visibility.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27049

The patch I submitted simply extracts the mathjax tarball into
/share/webapps/mathjax. Arch/Parabola use this kind of "webapps"
path. But, Debian puts it in /share/javascript/mathjax. So far, we have
not adopted any convention for Guix. What path convention should we
adopt? Is it necessary to distinguish between webapps and non-webapps,
like Arch/Parabola do, or is it better to just put it in a javascript
folder like Debian does? Are there other alternative approaches?

Should we have any prefix in the package name for javascript libraries
such as mathjax? Apparently, Debian uses the "libjs-" prefix. Also, it
might be a good idea to have a separate file
(gnu/packages/javascript.scm) for these javascript libraries.

Brendan also pointed out that mathjax is not just code served to web
browsers, but also used in programs like Calibre.

There are so many javascript libraries out there -- mathjax, d3.js,
jquery, etc, etc. Packaging them would be extremely useful for
self-hosting. But, we need to agree on good practices, so that we don't
run into trouble later.

Do share your thoughts.

Re: Packaging mathjax and other javascript libraries

[Pjotr Prins]

On Thu, May 25, 2017 at 10:30:25PM +0530, Arun Isaac wrote:
> There are so many javascript libraries out there -- mathjax, d3.js,
> jquery, etc, etc. Packaging them would be extremely useful for
> self-hosting. But, we need to agree on good practices, so that we don't
> run into trouble later.

Good timing. I have been using $PROFILE/lib/javascript/ to store
modules in line with python and ruby etc. Splitting out pure JS
modules and webapps makes sense to me. We also have clojurescript,
purescript, elm and others to consider - even if they generate JS. Is
JS going to be our object format?

-- 

Re: Packaging mathjax and other javascript libraries

[Ricardo Wurmus]

Arun Isaac <arunisaac@systemreboot.net> writes:

> A couple of days back, I submitted a patch packaging mathjax. My
> conversations with Brendan there raised some more general questions. So,
> I'm posting here for wider visibility.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27049
>
> The patch I submitted simply extracts the mathjax tarball into
> /share/webapps/mathjax. Arch/Parabola use this kind of "webapps"
> path. But, Debian puts it in /share/javascript/mathjax. So far, we have
> not adopted any convention for Guix. What path convention should we
> adopt? Is it necessary to distinguish between webapps and non-webapps,
> like Arch/Parabola do, or is it better to just put it in a javascript
> folder like Debian does? Are there other alternative approaches?

I would be in favour of doing it the Debian way.  It’s difficult to draw
a line between a web application and a JavaScript library, so I’d rather
not have to make a decision like that each time we package something
written in JavaScript.

> Should we have any prefix in the package name for javascript libraries
> such as mathjax? Apparently, Debian uses the "libjs-" prefix. Also, it
> might be a good idea to have a separate file
> (gnu/packages/javascript.scm) for these javascript libraries.

So far we have separated packages according to their purpose.  There are
a few exceptions, such as python.scm, which would best be split up.  If
possible I’d rather have JavaScript libraries in modules that indicate
what their purpose is.  General purpose frameworks, on the other hand,
could very well fit in a javascript.scm.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Packaging mathjax and other javascript libraries

[Arun Isaac]

Ricardo Wurmus writes:

>> The patch I submitted simply extracts the mathjax tarball into
>> /share/webapps/mathjax. Arch/Parabola use this kind of "webapps"
>> path. But, Debian puts it in /share/javascript/mathjax. So far, we have
>> not adopted any convention for Guix. What path convention should we
>> adopt? Is it necessary to distinguish between webapps and non-webapps,
>> like Arch/Parabola do, or is it better to just put it in a javascript
>> folder like Debian does? Are there other alternative approaches?
>
> I would be in favour of doing it the Debian way.  It’s difficult to draw
> a line between a web application and a JavaScript library, so I’d rather
> not have to make a decision like that each time we package something
> written in JavaScript.

I agree. Arch/Parabola even put packages like cgit and roundcube in a webapps
folder. However, in Guix, we don't treat these applications specially,
and I think we should continue that way.

>> Should we have any prefix in the package name for javascript libraries
>> such as mathjax? Apparently, Debian uses the "libjs-" prefix. Also, it
>> might be a good idea to have a separate file
>> (gnu/packages/javascript.scm) for these javascript libraries.
>
> So far we have separated packages according to their purpose.  There are
> a few exceptions, such as python.scm, which would best be split up.  If
> possible I’d rather have JavaScript libraries in modules that indicate
> what their purpose is.  General purpose frameworks, on the other hand,
> could very well fit in a javascript.scm.

I think mathjax being a kind of library, should be put in a
javascript.scm with a "javascript-" prefix. This is similar to the way
we treat python libraries with a "python-" prefix, emacs
packages/libraries with a "emacs-" prefix, etc. WDYT?

Pjotr Prins writes:

> We also have clojurescript, purescript, elm and others to consider -
> even if they generate JS. Is JS going to be our object format?

That's an interesting question. Should we even install the source code
after compiling these various languages to javascript? I am in favor of
only installing the compiled javascript to some path like
share/javascript/projectname/

Re: Packaging mathjax and other javascript libraries

[Ricardo Wurmus]

Arun Isaac <arunisaac@systemreboot.net> writes:

>> So far we have separated packages according to their purpose.  There are
>> a few exceptions, such as python.scm, which would best be split up.  If
>> possible I’d rather have JavaScript libraries in modules that indicate
>> what their purpose is.  General purpose frameworks, on the other hand,
>> could very well fit in a javascript.scm.
>
> I think mathjax being a kind of library, should be put in a
> javascript.scm with a "javascript-" prefix. This is similar to the way
> we treat python libraries with a "python-" prefix, emacs
> packages/libraries with a "emacs-" prefix, etc. WDYT?

Sounds good.  I would prefer a shorter prefix, though, such as “js-”.
We use “cl-” for Common Lisp, and I’m glad I don’t need to type so much
:)

> Pjotr Prins writes:
>
>> We also have clojurescript, purescript, elm and others to consider -
>> even if they generate JS. Is JS going to be our object format?
>
> That's an interesting question. Should we even install the source code
> after compiling these various languages to javascript? I am in favor of
> only installing the compiled javascript to some path like
> share/javascript/projectname/

Yes, only installing the compiled/minified JavaScript sounds like the
right thing to do.  Users can get the original sources with “guix build
-S”.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Packaging mathjax and other javascript libraries

[Arun Isaac]

Ricardo Wurmus writes:

> Arun Isaac <arunisaac@systemreboot.net> writes:
>
>>> So far we have separated packages according to their purpose.  There are
>>> a few exceptions, such as python.scm, which would best be split up.  If
>>> possible I’d rather have JavaScript libraries in modules that indicate
>>> what their purpose is.  General purpose frameworks, on the other hand,
>>> could very well fit in a javascript.scm.
>>
>> I think mathjax being a kind of library, should be put in a
>> javascript.scm with a "javascript-" prefix. This is similar to the way
>> we treat python libraries with a "python-" prefix, emacs
>> packages/libraries with a "emacs-" prefix, etc. WDYT?
>
> Sounds good.  I would prefer a shorter prefix, though, such as “js-”.
> We use “cl-” for Common Lisp, and I’m glad I don’t need to type so much
> :)

Ok, "js-" then! :-)

Re: Packaging mathjax and other javascript libraries

[Brendan Tildesley]

Ricardo Wurmus 於 2017-05-26 18:17 寫道:
> Arun Isaac <arunisaac@systemreboot.net> writes:
>
> [...]
> I would be in favour of doing it the Debian way.  It’s difficult to draw
> a line between a web application and a JavaScript library, so I’d rather
> not have to make a decision like that each time we package something
> written in JavaScript.
>
>> Should we have any prefix in the package name for javascript libraries
>> such as mathjax? Apparently, Debian uses the "libjs-" prefix. Also, it
>> might be a good idea to have a separate file
>> (gnu/packages/javascript.scm) for these javascript libraries.
> So far we have separated packages according to their purpose.  There are
> a few exceptions, such as python.scm, which would best be split up.  If
> possible I’d rather have JavaScript libraries in modules that indicate
> what their purpose is.  General purpose frameworks, on the other hand,
> could very well fit in a javascript.scm.
>
I also wondered if mathjax should be broken up into js-mathjax and
font-mathjax, since it is 180MiB or so. Some distros even just delete
some of the fonts.

Re: Packaging mathjax and other javascript libraries

[Arun Isaac]

> I also wondered if mathjax should be broken up into js-mathjax and
> font-mathjax, since it is 180MiB or so. Some distros even just delete
> some of the fonts.

I'm working on this as well. I'll send patches adding js-mathjax and
font-mathjax once they are ready.