Skip ahead to the Log Output section to see my problem.

Let's assume the following file structure:

  - Preamble.tex
 |- Libraries
   |- Addresses
      - addresses.sty
 |- Documents
   |- UserManual
      - UserManual.tex

Inside of Preamble.tex

% ----------------------
% Load Addresses Library

Inside of Addresses

\ProvidesPackage{addresses}[2016/03/01 Provides Addresses for Highly Specialized Services Documentation]


Inside of UserManual.tex


Log Output Snippet

Where is the version info on the addresses.sty line?

article.cls    2014/09/29 v1.4h Standard LaTeX document class
  • Not directly importnat here, but you shouldn't have a path in the argument of \usepackage: put addresses.sty where TeX can find it (local tree) and load just with \usepackge{addresses}.
    – Joseph Wright
    Mar 1 '16 at 8:40
  • @JosephWright It is not an option, unfortunately, because the entire documentation is self-contained in a version control system (we happen to be using subversion). A checkout should rely only on a complete and unmodified (for good maintenance practice) TeX Live Installation. This way, any user (on any host with TeX Live) can check out the source files and have a fully operational documentation system. Mar 1 '16 at 8:47
  • You can set TEXINPUTS or TEXMFHOME from a script or other build set up: there's not requirement that all 'local' files have to go into a single tree. (Though really if files are specific to a single project they should simply all be in the same directory.)
    – Joseph Wright
    Mar 1 '16 at 8:49
  • You must have a warning from latex that \usepackage{Libraries/Addresses/addresses} does not match addresses don't ignore warnings! Mar 1 '16 at 11:29

The mechanism in \usepackage, etc., assume that files are located 'where TeX can find them', i.e. either 'here', in a location specified by TEXINPUTS or in a TeX tree such as the main installation tree, one of those listed in TEXMFHOME, etc. Specifically, what happens here is:

  • LaTeX looks for a file Libraries/Addresses/addresses.sty, finds it and loads it
  • \ProvidesFile records version information in \ver@Libraries/Addresses/addresses.sty
  • \listfiles requests a file list, which contains the 'names' of all of the files loaded
  • The process for building a file list only looks for versions based on the file name itself, so looks for \ver@addresses.sty and produces no output as it doesn't exist

Notably, the same issue would happen if you try to load the same file twice: as far as the LaTeX mechanisms are concerned, addresses.sty, foo/addresses.sty and foo/bar/addresses.sty are distinct file names.

As the above shows, the systems build in to LaTeX strongly expect that files names are given not file paths. This can be handled by

  • Placing files 'here'
  • Placing them in a local TeX tree set up for access using TEXMFHOME (using an environmental variable or the MiKTeX manager where that is appropriate)
  • Adjusting TEXINPUTS to point to additional locations

Note that the latter mechanisms both allow multiple paths to be added, so this can be adjusted on a per-project basis.

  • Is there any way to trick LaTeX into setting \ver@addresses.sty despite being called \ver@foo/addresses.sty? I know TEXINPUTS is a good solution, but I can't be maintaining environment variables on every machine (especially since every developer has his or her own preferred folder naming scheme for SVN checkouts, which would break any TEXINPUTS). That is not a portable solution for a large operation (not yet anyway). Mar 1 '16 at 10:10
  • 1
    @macmadness86 using a path in \usepackage is basically an error obviously any part of latex can be redefined, but you shouldn't redefine that. If you really want to do that better to use \Providespackage{Libraries/Addresses/addresses} so that the declared name matches the name that you use in \usepackage Mar 1 '16 at 11:35
  • @DavidCarlisle Understood. I will have to do it this way until I find a portable solution for the paths as Joseph suggested. I'd prefer to do things the "clean" and "right" way. Mar 1 '16 at 18:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.