brucemiller / LaTeXML

LaTeXML: a TeX and LaTeX to XML/HTML/ePub/MathML translator.
http://dlmf.nist.gov/LaTeXML/
Other
961 stars 101 forks source link

only run expl3-dependent tests in continuous integration #2234

Closed dginev closed 1 year ago

dginev commented 1 year ago

This PR is essentially a repeat on my first attempt in #2045, and is one way to interpret the sentiment I recently expressed in #2175 and #2204.

Namely, I suggest we temporarily only run expl3-related tests in continuous integration, allowing systems where latexml's expl3 emulation is broken to still have a clean/successful installation. Those are currently two tests - glossary and si. Also, this is specifically targeted to the 0.8.8 release of latexml.

For the next, 0.8.9 release, I think Bruce has shown some convincing prototypes where both the performance in loading expl3 can be improved, as well as the robustness in interpretation, but that will require some sweeping changes to the pool-related internals of Core processing.

P.S. Attached with taking this route would be a suggestion to defer resolving #2204 until after the more ambitious approach to expl3 loading is in place.

brucemiller commented 1 year ago

Yeah, sadly it seems like it's time to do this. Hopefully we'll be able to back off soonish.

But since you've "formalized" the CI switch, shouldn't we tweak the existing CI tests to use the same tagging (to avoid surprises later)? Those seem to be t/83_expl3.t, t/170_grammar_coverage.t, t/97_manifest.t

dginev commented 1 year ago

Sure. I rebased to master and switched t/83_expl3.t to the new idiom.

But the other two cases - t/170_grammar_coverage.t and t/97_manifest.t are not testing individual .tex files, and thus do not rely on LaTeXML::Util::Test, so they can't really be unified more? At least I am not sure how that would look.

brucemiller commented 1 year ago

Cool! Thanks!