How to package executables

[Mojca Miklavec]

Hi,

On Sun, 19 Jul 2020 at 22:58, Louis wrote:
>
> I recently released a simple python package on CTAN [1] (simple in that
> is has no (python) dependencies). When I released it, Manfred Lotz (of
> the CTAN team) mentionned that it might be shipped with texlive, and
> advised me to ask for help on this mailing list.
>
> [1] https://www.ctan.org/pkg/spix

I'm asking just in case.

Given the super extra care about what commands may or may not be
executed by tex/latex: are there no security concerns over executing
random commands in shell? Or is it simply that we can (and should)
guarantee that tex/latex (at least for pdftex and xetex) etc. will not
themselves execute malicious code by accident, while it's totally up
to the user running spix to be aware that they need to manually check
the source code downloaded from internet before compiling anything?

**********

My second concern (less important, irrelevant to the question of how
to include etc.) is roughly the following:
    https://xkcd.com/927/

I certainly find the tool useful (assuming I would still be using latex).
But on the other hand the users now no longer have a clue whether to
compile the file with tex, latex, pdftex, pdflatex, xetex, xelatex,
luatex, lualatex, context, mklatex or spix. It's not like you could
educate users to simply always run "spix hello.tex" to get their job
done on any given .tex file. And anyone writing the file will need to
possess some knowledge about how to write the code to be compliant
with the tool. There's no special suffix and no identifiable header to
distinguish spix-compliant TeX documents (neither manually nor by
machine) from the rest of the "regular" TeX document, and if there are
ten .tex documents in the folder (say, for different chapters), it's
still not clear which one to process. (I mean: if the tool became
widely adopted, at some point vi, emacs, texshop, texworks, textmate,
... could in principle automatically identify that the file is
spix-compatible and process it with spix. Not yet sure if this could
be reliably done with the current design.) It's still useful in many
cases and can spare the author lots of headaches and typing when
processing complex workflows. It's much easier to write than a
Makefile (but you also cannot do stuff like "only run bibtex if
something has changed in the bib database", or "only fetch that large
image from the internet if the file doesn't already exist locally").
So I'm not in any way arguing against inclusion, just pointing out
some potential drawbacks.

ConTeXt comes with this kind of functionality built-in since a very
long time (but the number of runs, processing of bibliography,
metapost etc. is done automatically; and picking the correct engine
like pdftex/xetex/luatex was also there).

It certainly sounds like a core functionality that is extremely
helpful and useful in the LaTeX world as well.
And the more people stick to the same standard, the more useful it becomes.
By having such an important script written in lua, many of the
packaging nightmares could vanish.
And by some coordinated effort with the core LaTeX team, I guess that
one could arrive at a single solution that gets "officially promoted"
as the recommended way to pick the correct engine, run complex
workflows, with improved security etc. Or maybe I'm just too big of an
optimist?

Mojca