Inquiry regarding contributing a Rust-based package to TeX Live
luigi scarso <[email protected]> Sat, 7 Mar 2026 20:49:03 +0100
| Newsgroups | gmane.comp.tex.live |
|---|---|
| Message-ID | <CAG5iGsASfY7HMcoL0-AKw0h02wY0Jz7CcpKm4eGjPaDv4PJHBw@mail.gmail.com> |
While it's always possible to upload a package to CTAN that requires --shell-escape and provides instructions on where to find the other necessary resources, I think that we're essentially talking about shared object plugins and TeXLive. This isn't new; many programs have plugins or rely on external shared objects to add functionality or enhance existing ones, and the advantages and disadvantages are well known. Based on Karl's considerations, my own are: 1) It's possible to provide plugin management (e.g., a reference directory, how to load a plugin, etc.) -- in short, an infrastructure -- but this shouldn't force TexLive to provide plugins, nor change its security approach; 2) It makes sense to consider a TexLive "affiliate" site, a plugin repository that follows TexLive's evolution. Speaking only of luatex /luahbtex, and from a plugin perspective, there are two options: 1) luaffi: Pros: a lua binding file Cons: luaffi is not officially supported by Lua, and I personally recommend it only in specific cases. Furthermore, it presents the security issues already mentioned; 2) the canonical route (hence two shared objects: the binding and the plugin) : Pros: It's the most secure route Cons: It requires compiling the binding In this case, even if it were possible to modify luatex to load a plugin without enabling --shell-escape, the security issues remain (bugs that create segment faults, malicious plugins, etc.) -- common to all programs that use plugins, and a problem with a plugin is not a problem with the program unless it is officially distributed with the program itself. I think bugs can be reduced if the binding is compiled using SWIG (which handles the Lua <-> C part) and if the plugin is in Rust and pays particular attention to the Rust <-> C part. Rust should have the advantage of making it (much?) easier to compile the plugin for multiple platforms, but if the binding is in C, this advantage is not exploited (with luaffi, however, it is). For the record: in TexLive 2026, ConTeXt Mkiv still features some plugin examples with luaffi (sqlite) and swig. The latter was archived 10 years ago and is no longer supported by Mkiv, but the concept remains valid. -- luigi