Windows tester for a library?

Question

I don't know if this is the place to ask that, but I don't know where else…

So I just finished the first version of my robust-externalize library (after doing an important rewrite, thanks a lot everybody here for the help), but before pushing it to CTAN, I'd like to check if it is compatible with windows (I need -shell-escape and I don't really know if the command I used are actually really cross platform, they should but who knows how windows reacts).

Would someone be kind enough to test it for me, as I do not have any windows with me? The procedure to test is simple:

$ git clone https://github.com/leo-colisson/robust-externalize
$ cd robust-externalize/doc

Then, to disable the build of bash code (not available on windows), just modify the file doc/robust-externalize.tex by adding after \begin{document}:

\robExtConfigure{
  % bash code will not be compiled (bash does not exist on windows)
  bash/.append style={
    disable externalization
  },
}

and compile the file using:

$ pdflatex -shell-escape robust-externalize.tex
$ pdflatex -shell-escape robust-externalize.tex

(if you are afraid by the -shell-escape, you can also add a line |enable manual mode,| in \robExtConfigure and run the commands in |JOBNAME-robExt-compile-missing-figures.sh| manually, but part of the goal is to check if -shell-escape works as expected)

If you get no error, and if the code produces a file robust-externalize.pdf that looks like this one https://raw.githubusercontent.com/leo-colisson/robust-externalize/master/doc/robust-externalize.pdf then everything is fine! You can either report it here, or in the github issue created for that! Thanks!

Answer 1

While it would be great to have a robust way to externalise images and other things, please reconsider pushing this to CTAN in its current state. The clarity of expl3 code requires people to abide by the naming conventions and use functions which include, rather than exclude, checks for conflicts.

\cs_set:Nn \str_set_hash_robust:Nn % No!

You really, really, really shouldn't do this. Not only is str the name of an existing module, it is the name of a kernel module. You are not adding this as a member of the team responsible for that module, so you should choose your own module name and all the functions and variables you create should be prefixed by that module name.

You should also not do set unless you've previously done new. And you absolutely definitely shouldn't do it with a name which rightfully belongs to the existing module str.

\str_set:Nn {#1} {#2} % No!

is incorrect and the same for similar constructions. Wherever you have N, you shouldn't have braces. So

\str_set:Nn #1 {#2}

Your variables are systematically misnamed as they all omit the suffix which should indicate the kind of variable it is.

\str_new:N \l_robExt_template % No!

is malformed, for example, and should be

\str_new:N \l_robExt_template_str

This is true for every expl3 variable you create.

Note that you are also declaring this variable to be suitable for public use. That means users can legitimately expect updates to take account of the fact that they may be using \l_robExt_currentCompilationCommand, for example. This is fine if you are prepared to support this, but it is somewhat unusual for a package to make use of no internal functions or variables.

You are opening at least 3 new writes. That is a hefty chunk of resources for a package with a relatively limited role. TeX allows at most 16 writes. Your package demands almost 20% of them. (LuaTeX allows 128, so less of a concern.) This can be worked around with morewrites, but I don't recall using any package which helped itself to three (one only for temporary writes?).

If commands, functions or variables shouldn't be called by end users, name them appropriately. For expl3, the guidance is clear. For 2e commands, things are less well-defined, but \robExt@... would flag up the likelihood the command isn't meant for external use. Don't rely on comments or documentation to communicate this.

Although you declare local variables, you don't seem to make much use of grouping. Perhaps this is necessary and by-design but, if not, it is worth seeing whether you can do things more locally.

Answer 2

Actually, I managed to run an old windows VM, and it works!