| Message ID | 20200816070318.18642-2-mail@brendan.scot |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#42885,1/4] gnu: ebook.scm: remove duplicate module import. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | success | View Laminar job |
On Sun, Aug 16, 2020 at 05:03:16PM +1000, Brendan Tildesley wrote: > * gnu/packages/javascript.scm: (mathjax-bin): New variable > + (description "MathJax is a JavaScript display engine for LaTeX, MathML, > +and AsciiMath notation that works in all modern browsers. It requires no > +plugins or software to be installed on the browser. So the page author can > +write web documents that include mathematics and be confident that readers will > +be able to view it naturally and easily. > + > +The package is derived from not the true source but the built version of > +MathJax 3 for distribution by upstream. This package should eventually be > +replaced my a package built directly from the source at > +https://github.com/mathjax/MathJax-src.") I'm not really familiar with the state of JavaScript in Guix. However, Guix generally only includes packages built from source. Is this a case where the package has bene "minified"? Or, in what way is not built from source?
>> +The package is derived from not the true source but the built version of >> +MathJax 3 for distribution by upstream. This package should eventually be >> +replaced my a package built directly from the source at >> +https://github.com/mathjax/MathJax-src.") > > I'm not really familiar with the state of JavaScript in Guix. However, > Guix generally only includes packages built from source. If I understand correctly, we already have a mathjax package built from source. See js-mathjax.
On August 24, 2020 2:25:16 PM GMT+10:00, Arun Isaac <arunisaac@systemreboot.net> wrote: > >>> +The package is derived from not the true source but the built >version of >>> +MathJax 3 for distribution by upstream. This package should >eventually be >>> +replaced my a package built directly from the source at >>> +https://github.com/mathjax/MathJax-src.") >> >> I'm not really familiar with the state of JavaScript in Guix. >However, >> Guix generally only includes packages built from source. > >If I understand correctly, we already have a mathjax package built from >source. See js-mathjax. Mathjax 3 is a complete rewrite of mathjax 2. I had thought js-mathjax was just the component files too and not truely built from source. Maybe I was wrong. Currently, building this from the true source requires a huge number of js packages and we haven't got a npm importer and full JavaScript bootstrap yet so I wasn't sure what to do. If you like we can ignore this and I can modify calibre to disable mathjax for now since I don't think it works with the old mathjax 2. I would like to work on getting more JavaScript in to guix properly
> I had thought js-mathjax was just the component files too and not > truely built from source. Maybe I was wrong. Currently, building this > from the true source requires a huge number of js packages and we > haven't got a npm importer and full JavaScript bootstrap yet so I > wasn't sure what to do. True. js-mathjax is not truly built from source. A true source build will properly depend on a huge number of other js packaces. js-mathjax only redoes the minification step. In light of this, perhaps we should remove js-mathjax from Guix. But, I'm not sure. > If you like we can ignore this and I can modify calibre to disable > mathjax for now since I don't think it works with the old mathjax 2. I > would like to work on getting more JavaScript in to guix properly Yes, disabling mathjax for calibre is a good way to go if the functionality is not too critical. But, I don't know much about calibre. So, someone else should take a call.
On August 24, 2020 4:44:37 PM GMT+10:00, Arun Isaac <arunisaac@systemreboot.net> wrote: > >> I had thought js-mathjax was just the component files too and not >> truely built from source. Maybe I was wrong. Currently, building this >> from the true source requires a huge number of js packages and we >> haven't got a npm importer and full JavaScript bootstrap yet so I >> wasn't sure what to do. > >True. js-mathjax is not truly built from source. A true source build >will properly depend on a huge number of other js packaces. js-mathjax >only redoes the minification step. In light of this, perhaps we should >remove js-mathjax from Guix. But, I'm not sure. > >> If you like we can ignore this and I can modify calibre to disable >> mathjax for now since I don't think it works with the old mathjax 2. >I >> would like to work on getting more JavaScript in to guix properly > >Yes, disabling mathjax for calibre is a good way to go if the >functionality is not too critical. But, I don't know much about >calibre. So, someone else should take a call.
On August 24, 2020 4:44:37 PM GMT+10:00, Arun Isaac <arunisaac@systemreboot.net> wrote: > >> I had thought js-mathjax was just the component files too and not >> truely built from source. Maybe I was wrong. Currently, building this >> from the true source requires a huge number of js packages and we >> haven't got a npm importer and full JavaScript bootstrap yet so I >> wasn't sure what to do. > >True. js-mathjax is not truly built from source. A true source build >will properly depend on a huge number of other js packaces. js-mathjax >only redoes the minification step. In light of this, perhaps we should >remove js-mathjax from Guix. But, I'm not sure. > >> If you like we can ignore this and I can modify calibre to disable >> mathjax for now since I don't think it works with the old mathjax 2. >I >> would like to work on getting more JavaScript in to guix properly > >Yes, disabling mathjax for calibre is a good way to go if the >functionality is not too critical. But, I don't know much about >calibre. So, someone else should take a call. Its just for rendering math in the eBook-viewer for books that include it. It shouldn't be essential. The reason I felt OK adding it is because its not like its actually proprietary, its just we haven't gotten around to integrating JavaScript into guix yet fully, and it doesn't look like that will happen any time soon.
Hello there! Arun, Leo, what’s the status of this patch series? https://issues.guix.gnu.org/42885 Can it be applied? Brendan, to make it clear what the latest version of the patch series is (next time), consider adding a “v2” etc. suffix to the subject, like so: git format-patch --subject-prefix="PATCH v2" … Thanks, Ludo’.
Hello, On Fri, Sep 04, 2020 at 11:02:46AM +0200, Ludovic Courtès wrote: > Arun, Leo, what’s the status of this patch series? > https://issues.guix.gnu.org/42885 why is the variable called mathjax-bin? Should it not be mathjax? By the way, there is a version 3.1.0 now. Andreas
Arun Isaac <arunisaac@systemreboot.net> writes: >> I had thought js-mathjax was just the component files too and not >> truely built from source. Maybe I was wrong. Currently, building this >> from the true source requires a huge number of js packages and we >> haven't got a npm importer and full JavaScript bootstrap yet so I >> wasn't sure what to do. > > True. js-mathjax is not truly built from source. A true source build > will properly depend on a huge number of other js packaces. js-mathjax > only redoes the minification step. In light of this, perhaps we should > remove js-mathjax from Guix. But, I'm not sure. js-mathjax does not contain minified JavaScript. The code is in editable and readable form although it is not in the form that upstream uses for development. In this case I still consider it to be actual source code, because for the purposes of Guix this is the preferred format (given that we have no way of building the sources in the format that is used by upstream).
> Arun, Leo, what’s the status of this patch series? > > https://issues.guix.gnu.org/42885 > > Can it be applied? Ricardo has clarified that we may consider the existing js-mathjax 2.7.2 package to have been built from source even though it isn't the form upstream uses for development. No problems there. But, like Brendan said, mathjax 3 is quite a different beast. With mathjax 2, the source was in javascript, and our build system had merely to minify it. But mathjax 3 is written in typescript that gets compiled into javascript and then combined into "web component files" (this is the first I'm hearing of web components and I'm not entirely clear what they are). Since we don't have a typescript build system, packaging mathjax 3 may be non-trivial. So, we should proceed with updating calibre without mathjax support. > Brendan, to make it clear what the latest version of the patch series is > (next time), consider adding a “v2” etc. suffix to the subject, like so: > > git format-patch --subject-prefix="PATCH v2" … You could also do the slightly shorter git format-patch -v2 ... Cheers!
Arun Isaac <arunisaac@systemreboot.net> writes: >> Arun, Leo, what’s the status of this patch series? >> >> https://issues.guix.gnu.org/42885 >> >> Can it be applied? > > Ricardo has clarified that we may consider the existing js-mathjax 2.7.2 > package to have been built from source even though it isn't the form > upstream uses for development. No problems there. > > But, like Brendan said, mathjax 3 is quite a different beast. With > mathjax 2, the source was in javascript, and our build system had merely > to minify it. But mathjax 3 is written in typescript that gets compiled > into javascript and then combined into "web component files" (this is > the first I'm hearing of web components and I'm not entirely clear what > they are). Since we don't have a typescript build system, packaging > mathjax 3 may be non-trivial. So, we should proceed with updating > calibre without mathjax support. There may be a way to transpile the TypeScript sources with swc, a babel-like transpiler with TypeScript support; it’s written in Rust, so there may be a way to work around the JavaScript packaging problem.
> There may be a way to transpile the TypeScript sources with swc, a > babel-like transpiler with TypeScript support; it’s written in Rust, so > there may be a way to work around the JavaScript packaging problem. I am packaging swc for Guix. I'm running into some unstable feature issues with Rust, but otherwise things are going well. I will report on further progress by tonight.
Arun Isaac <arunisaac@systemreboot.net> writes: >> There may be a way to transpile the TypeScript sources with swc, a >> babel-like transpiler with TypeScript support; it’s written in Rust, so >> there may be a way to work around the JavaScript packaging problem. > > I am packaging swc for Guix. I'm running into some unstable feature > issues with Rust, but otherwise things are going well. I will report on > further progress by tonight. Oh, me too. I’m currently at rust-napi@0.4.
>> I am packaging swc for Guix. I'm running into some unstable feature >> issues with Rust, but otherwise things are going well. I will report on >> further progress by tonight. > > Oh, me too. Oops, hopefully we haven't duplicated too much work. Packaging rust programs is a much deeper rabbit hole than I imagined! But, I'm making progress, and will hopefully be done given some more time. Will keep you posted.
Hi, I have finished packaging swc. I am now mid-way through cleaning up and committing my changes. Considering the number of commits, that alone might take a couple more days. I will push my changes to a wip-swc branch and let you know. But, I also have some bad news. swc is not entirely written in rust. Its CLI, swc-cli, is a separate package and uses node. So, packaging that may be yet another deep rabbit hole. Regards, Arun
Hi Arun, > I have finished packaging swc. I am now mid-way through cleaning up and > committing my changes. Considering the number of commits, that alone > might take a couple more days. I will push my changes to a wip-swc > branch and let you know. Wow, thank you very much! > But, I also have some bad news. swc is not entirely written in rust. Its > CLI, swc-cli, is a separate package and uses node. So, packaging that > may be yet another deep rabbit hole. I expected as much, but I was hoping that we could invoke it some other way, much like we invoke uglify-js (the Common Lisp package) with a little custom wrapper.
I have pushed my commits to a new wip-swc branch. A few questions and discussion points below. Considering that only the source of rust dependencies is used, should those packages successfully build on their own? In the wip-swc branch, I have only verified that the rust-swc package builds. There may be some dependencies which fail to build on their own. Related to the previous question, what is the purpose of the #:skip-build? argument? Should it be set to #t for all dependency packages? While working on this patchset, I hacked the crate importer a bit to make my life easier. In particular, I modified it to correctly append the version to the package variable name. This requires a slightly more general recursive importer than we have currently. The current recursive importer assumes that we will package only one version for each package. That assumption does not stand for rust crates. We also don't always need to put the minor version into the package variable name. For example, rust-syn-1 is sufficient. rust-syn-1.0 is not required. The exact rules follow from https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html I improved the crate importer to better understand these version requirement rules and put packages of the correct version into the #:cargo-inputs and #:cargo-development-inputs fields. I will send patches for these crate importer improvements separately after this patchset is approved. We also need some automated way to "garbage collect" old versions of packages in crates-io.scm. crates-io.scm is getting quite large, and I suspect many packages in there are old versions that are not really necessary. > I expected as much, but I was hoping that we could invoke it some other > way, much like we invoke uglify-js (the Common Lisp package) with a > little custom wrapper. That is a good idea. But, I have never written any rust. Perhaps someone who is more familiar with rust should write it.
On 21/9/20 8:36 pm, Arun Isaac wrote: > ... > While working on this patchset, I hacked the crate importer a bit to > make my life easier. In particular, I modified it to correctly append > the version to the package variable name. This requires a slightly more > general recursive importer than we have currently. The current recursive > importer assumes that we will package only one version for each > package. That assumption does not stand for rust crates. Are you aware of this importer: https://issues.guix.gnu.org/issue/38408/ ?
>> While working on this patchset, I hacked the crate importer a bit to >> make my life easier. > Are you aware of this importer: https://issues.guix.gnu.org/issue/38408/ ? Oh, I wasn't aware of this importer. It seems to address my concerns. So, I'll just wait for it to get merged into master.
BTW, is it possible for your wip-swc branch to be merged into master? I found my self building a package of my own starting from this branch because it includes the rust packages I needed. Is there any reason it can't be done? It would be convenient for me at least.
> BTW, is it possible for your wip-swc branch to be merged into master?
I think it can be done. I was just waiting for someone to review and
approve it.
@Ricardo: Shall I go ahead and merge?
I have merged wip-swc into master. Should this bug report be closed now? Is there any pending work here related to calibre? We need a typescript build system that uses swc. But, we should handle that in a separate bug report. Thanks!
On 12/10/20 5:23 pm, Arun Isaac wrote: > I have merged wip-swc into master. Should this bug report be closed now? > Is there any pending work here related to calibre? We need a typescript > build system that uses swc. But, we should handle that in a separate bug > report. > > Thanks! Thank you very much. I'm kind of worried how long it will take to get that build system. Even if we have it, will it really succeed at building MathJax so easily? If it's going to take a while, I'm tempted to just update Calibre without mathjax support. In theory I'm willing to do work to help but it all seems rather advanced for me, so i'm glad to see you make progress. What's the next step? Calibre 5+ is out now which is on python3. I could even create a calibre-next so that both calibre@4.18.0 exists and calibre will be calibre@5.0.1, utilizing Guix's design.
> Thank you very much. :-) > I'm kind of worried how long it will take to get that build system. Even > if we have it, will it really succeed at building MathJax so easily? If > it's going to take a while, I'm tempted to just update Calibre without > mathjax support. In theory I'm willing to do work to help but it all > seems rather advanced for me, so i'm glad to see you make progress. > What's the next step? True, I have similar concerns too. The next step, like Ricardo said, is to write a simple rust script that uses rust-swc to compile typescript to javascript. I am unfamiliar with both rust and typescript. So, if I am to do it, I would need some time. If someone else volunteers to do it, that would be great. > Calibre 5+ is out now which is on python3. I could even create a > calibre-next so that both calibre@4.18.0 exists and calibre will be > calibre@5.0.1, utilizing Guix's design. I think we shouldn't let the typescript build system and mathjax block calibre. If I understand correctly, calibre depends on mathjax only optionally. So, you should go ahead with your work on calibre regardless of what happens with mathjax.
Arun Isaac <arunisaac@systemreboot.net> writes: >> I'm kind of worried how long it will take to get that build system. Even >> if we have it, will it really succeed at building MathJax so easily? If >> it's going to take a while, I'm tempted to just update Calibre without >> mathjax support. In theory I'm willing to do work to help but it all >> seems rather advanced for me, so i'm glad to see you make progress. >> What's the next step? > > True, I have similar concerns too. The next step, like Ricardo said, is > to write a simple rust script that uses rust-swc to compile typescript > to javascript. I am unfamiliar with both rust and typescript. So, if I > am to do it, I would need some time. If someone else volunteers to do > it, that would be great. I looked at this today, but my rust-foo is very, very weak. I tried to compile this: https://github.com/swc-project/swc/blob/master/examples/usage.rs jlicht told me on IRC that we also have a package for esbuild now, which could also be used for transpiling TypeScript to JS.
> I looked at this today, but my rust-foo is very, very weak. > I tried to compile this: > > https://github.com/swc-project/swc/blob/master/examples/usage.rs I managed to get this working. Please see the attached tarball. The steps to test are: Unpack the tarball and change directory. Clone the swc git repo. Build and run using cargo. --8<---------------cut here---------------start------------->8--- tar xvf miniswc.tar.gz cd miniswc git clone https://github.com/swc-project cargo run --8<---------------cut here---------------end--------------->8--- src/main.rs in the tarball is a slightly modified version of examples/usage.rs in the swc git repo. On running, it transpiles the file foo.ts and outputs to stdout. The next step is to see if this is any good for building MathJax from source. Cheers!
Hey ho! What’s the status of this Calibre update? https://issues.guix.gnu.org/42885 It it waiting on the SWC thing? Thanks in advance, :-) Ludo’.
diff --git a/gnu/packages/javascript.scm b/gnu/packages/javascript.scm index d5ff5bffee..d6a66a1482 100644 --- a/gnu/packages/javascript.scm +++ b/gnu/packages/javascript.scm @@ -4,6 +4,7 @@ ;;; Copyright © 2017, 2018 Tobias Geerinckx-Rice <me@tobias.gr> ;;; Copyright © 2017, 2018, 2019, 2020 Efraim Flashner <efraim@flashner.co.il> ;;; Copyright © 2018 Nicolas Goaziou <mail@nicolasgoaziou.fr> +;;; Copyright © 2020 Brendan Tildesley <mail@brendan.scot> ;;; ;;; This file is part of GNU Guix. ;;; @@ -128,6 +129,45 @@ plugins or software to be installed on the browser. So the page author can write web documents that include mathematics and be confident that readers will be able to view it naturally and easily."))) +(define-public mathjax-bin + (package + (name "mathjax") + (version "3.0.5") + (source + (origin + (method git-fetch) + (uri (git-reference + (url "https://github.com/mathjax/MathJax") + (commit version))) + (file-name (git-file-name name version)) + (sha256 + (base32 + "1zd0chn0cjahi28qv3nzshwljz2hgmj6lizyvvd8qs89gsx0z3h9")))) + (build-system trivial-build-system) + (arguments + `(#:modules ((guix build utils)) + #:builder + (begin + (use-modules (guix build utils) + (ice-9 match)) + (let ((install-directory (string-append %output "/lib/node_modules/mathjax"))) + (mkdir-p install-directory) + (copy-recursively (string-append (assoc-ref %build-inputs "source")) + install-directory))))) + (home-page "https://www.mathjax.org/") + (synopsis "JavaScript display engine for LaTeX, MathML, and AsciiMath (prebuilt)") + (description "MathJax is a JavaScript display engine for LaTeX, MathML, +and AsciiMath notation that works in all modern browsers. It requires no +plugins or software to be installed on the browser. So the page author can +write web documents that include mathematics and be confident that readers will +be able to view it naturally and easily. + +The package is derived from not the true source but the built version of +MathJax 3 for distribution by upstream. This package should eventually be +replaced my a package built directly from the source at +https://github.com/mathjax/MathJax-src.") + (license license:asl2.0))) + (define-public js-respond (package (name "js-respond")