how to ensure package dependencies are satisfied?

I am working on a script that uses tikz to create standalone graphics. I would like to ensure that the graphics can be compiled by anyone with a basic TeX installation, so i am looking for ways to provide required files with the script. My dependencies are

• the tikz package
• the tikz library shapes.geometric and
• the standalone class.

My Questions are:

Is there a way for me to ensure that another user (having TeX installed but not necessarily the dependencies) can use my scripts without having to install anything?

Can i just put .sty and .cls files into the same folder the graphics are compiled from?

• Welcome to TeX.SX! Compile it on your machine and copy all files you'll find in the log which are not "absolutely basic" (i.e. the files that might relate to TikZ) to the folder. – TeXnician Jan 1 '18 at 13:05
• you can do that but generally it's not a good idea, local copies of standard files like tikz have a habit of being installed in the wrong place and being used for other documents masking the standard versions installed with tex (that get updated as required but not used if they are masked by a local copy) – David Carlisle Jan 1 '18 at 13:20
• I would rather rely on a pretty extended installation of MiKTeX, MacTeX oder TeXLive rather. This should be possible nowadays without much effort – user31729 Jan 1 '18 at 13:26

Disclaimer

Generally, I'm inclined to concur with the comments and advise against this. I'd rather recommend informing people of the packages they will need, and how and where to get and install them. With that said, I have looked into long-term archivability of my own TeX projects a few times and that problem goes in a similar direction: How to make sure that I still have the package and class files which were used to originally create a document so that I can still compile it in 10 years without having to change a bunch of stuff because incompatible changes have been made to the packages (granted -- not a very common occurrence in the TeX world, at least in my experience).

I'm afraid though that the solutions I have found so far are not entirely satisfactory to me yet. Some patching may be required, and potentially manual intervention here and there. If somebody knows a better way, I would be rather interested in that.

Prerequisites

On the machine which creates the package, you will need:

Example

main.tex (created by user)

Add RequirePackage[snapshot} before the \documentclass in your file:

\RequirePackage{snapshot}
\documentclass{article}
\usepackage{lipsum}
\usepackage{tikz}
\usetikzlibrary{positioning,arrows.meta}
\begin{document}
\lipsum[1]
\begin{tikzpicture}
\node (a) at (0,0) {A};
\node (b) [right=of a] {B};
\draw[-Latex] (0,-2) -- (4,-1);
\end{tikzpicture}
\end{document}


Then compile the document.

main.dep (automatically generated)

It will create a file main.dep, which will contain a list of files and their versions which were used to compile your document. In our example, it will look like this (shortened):

\RequireVersions{
*{application}{TeX}     {1990/03/25 v3.x}
*{format} {LaTeX2e}     {2017-04-15 v2.e}
*{package}{snapshot}    {2002/03/05 v1.14}
*{class}  {article}     {2014/09/29 v1.4h}
*{file}   {size10.clo}  {2014/09/29 v1.4h}
*{package}{lipsum}      {2014/07/27 v1.3}
*{package}{tikz}        {2015/08/07 v3.0.1a}

.......

*{package}{pdftexcmds}  {2017/03/19 v0.25}
*{package}{ifpdf}       {2017/03/15 v3.2}
*{file}   {epstopdf-sys.cfg}{2010/07/13 v1.3}
}


NOTE: This process is not perfect and I have had it happen that I need to manually edit this file a bit here and there on some projects. I've even had to occasionally need to remove a line which was causing some sort of weird recursion error (if I recall correctly -- it's been a while).

bundledoc

bundledoc is a Perl script which will use that .dep file to create an archive of the files needed to compile your document and then package them up. On Linux, that will be a .tar.gz file by default. Haven't tried it on Windows. bundledoc is configurable though, a .zip file should be feasible (here's the config example I used on my thesis if you're curious).

Caveats

Due to Perl updates, bundledoc may or may not run on recent Perl versions. Manual adjustments to the script were needed as follows to get it to work for me. For this, I copied the system-wide file (/usr/bin/bundledoc in my case) to my local project directory.

First, I needed to add the module File::Temp somewhere at the start:

use File::Temp;


(Also, obviously, make sure you actually have that module available.)

Secondly: Line 137 (136 if you haven't yet added File::Temp): The regex is no longer compliant with Perl's requirements. You need to escape the opening brace and change the double quotes to single quotes. Old:

my $braced = "{([^\}]*)}"; # Regular expression for a braced name  New: my$braced = '\{([^\}]*)}';   # Regular expression for a braced name


Now I can run my local copy with

./bundledoc main.dep


However, the process does not seem to be quite perfect. Specifically, it is not picking up TikZ libraries correctly. We can tell bundledoc to include additional files on top of the ones in the .dep file with the --include option:

./bundledoc '--include=/usr/share/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/*positioning*tex' \
'--include=/usr/share/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/*arrows*tex' \
main.dep


NOTE: You can of course work without wild cards and just specify the full filenames. Also, if you do use wildcards, make sure the wildcards actually go to bundledoc and not to your shell (hence the single quotes here -- you could also escape them, depending on your shell).

This will pick up three TikZ library files and put them into the archive as well (at least on my system). I have not verified if these are actually all the files we need in this example, but you get the idea:

• tikzlibraryarrows.code.tex
• tikzlibrarypositioning.code.tex
• tikzlibraryshapes.arrows.code.tex

I will admit that I have not thoroughly tested how to make sure that those library files are actually properly used by your project if the system-wide files are not found (or if you just want to use the local ones, no matter what). I would expect some manual fiddling to be required, to be honest.

Conclusion

The result will be a tarball (or whichever other archive format you have specified). But I have found it a rather cumbersome process to make sure that it contains truly, certainly, absolutely surely, all the files which are needed, and that the target machine does actually use those files when compiling the document.

Additionally, some updates to packages might actually be desirable to have, of course, in which case you will need to re-distribute the archive to make sure people have the latest versions.

Personally, I have done this for some important projects of mine (my thesis, as said), but it's not something I habitually do, and even for those projects where I have done it, I tend to prefer working with the regular project files and the system-wide TeX distribution rather than putting myself through this process. It's an emergency solution for long-term archival purposes for me, but that's about it. I'm not sure I'd subject myself to this for a regularly used workflow. But one's mileage will vary, and maybe somebody finds a more convenient solution.