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.textikzlibrarypositioning.code.textikzlibraryshapes.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.
