all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Packaging mathjax and other javascript libraries
@ 2017-05-25 17:00 Arun Isaac
  2017-05-25 18:20 ` Pjotr Prins
  2017-05-26  8:17 ` Ricardo Wurmus
  0 siblings, 2 replies; 8+ messages in thread
From: Arun Isaac @ 2017-05-25 17:00 UTC (permalink / raw)
  To: guix-devel


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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Packaging mathjax and other javascript libraries
  2017-05-25 17:00 Packaging mathjax and other javascript libraries Arun Isaac
@ 2017-05-25 18:20 ` Pjotr Prins
  2017-05-26  8:17 ` Ricardo Wurmus
  1 sibling, 0 replies; 8+ messages in thread
From: Pjotr Prins @ 2017-05-25 18:20 UTC (permalink / raw)
  To: Arun Isaac; +Cc: guix-devel

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?

-- 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Packaging mathjax and other javascript libraries
  2017-05-25 17:00 Packaging mathjax and other javascript libraries Arun Isaac
  2017-05-25 18:20 ` Pjotr Prins
@ 2017-05-26  8:17 ` Ricardo Wurmus
  2017-05-27 18:56   ` Arun Isaac
  2017-05-28 13:26   ` Brendan Tildesley
  1 sibling, 2 replies; 8+ messages in thread
From: Ricardo Wurmus @ 2017-05-26  8:17 UTC (permalink / raw)
  To: Arun Isaac; +Cc: guix-devel


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Packaging mathjax and other javascript libraries
  2017-05-26  8:17 ` Ricardo Wurmus
@ 2017-05-27 18:56   ` Arun Isaac
  2017-05-27 21:17     ` Ricardo Wurmus
  2017-05-28 13:26   ` Brendan Tildesley
  1 sibling, 1 reply; 8+ messages in thread
From: Arun Isaac @ 2017-05-27 18:56 UTC (permalink / raw)
  To: guix-devel


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/

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Packaging mathjax and other javascript libraries
  2017-05-27 18:56   ` Arun Isaac
@ 2017-05-27 21:17     ` Ricardo Wurmus
  2017-05-28  6:03       ` Arun Isaac
  0 siblings, 1 reply; 8+ messages in thread
From: Ricardo Wurmus @ 2017-05-27 21:17 UTC (permalink / raw)
  To: Arun Isaac; +Cc: guix-devel


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Packaging mathjax and other javascript libraries
  2017-05-27 21:17     ` Ricardo Wurmus
@ 2017-05-28  6:03       ` Arun Isaac
  0 siblings, 0 replies; 8+ messages in thread
From: Arun Isaac @ 2017-05-28  6:03 UTC (permalink / raw)
  To: guix-devel


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! :-)

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Packaging mathjax and other javascript libraries
  2017-05-26  8:17 ` Ricardo Wurmus
  2017-05-27 18:56   ` Arun Isaac
@ 2017-05-28 13:26   ` Brendan Tildesley
  2017-05-28 18:45     ` Arun Isaac
  1 sibling, 1 reply; 8+ messages in thread
From: Brendan Tildesley @ 2017-05-28 13:26 UTC (permalink / raw)
  To: guix-devel

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Packaging mathjax and other javascript libraries
  2017-05-28 13:26   ` Brendan Tildesley
@ 2017-05-28 18:45     ` Arun Isaac
  0 siblings, 0 replies; 8+ messages in thread
From: Arun Isaac @ 2017-05-28 18:45 UTC (permalink / raw)
  To: guix-devel


> 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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-05-28 18:46 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-05-25 17:00 Packaging mathjax and other javascript libraries Arun Isaac
2017-05-25 18:20 ` Pjotr Prins
2017-05-26  8:17 ` Ricardo Wurmus
2017-05-27 18:56   ` Arun Isaac
2017-05-27 21:17     ` Ricardo Wurmus
2017-05-28  6:03       ` Arun Isaac
2017-05-28 13:26   ` Brendan Tildesley
2017-05-28 18:45     ` Arun Isaac

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.