To inlcude our self-written class we are currently using relative paths (\documentclass{../ourclass}
), which triggers a warning (wrong class provided) and is rather ugly. The solution to this problem is discussed in these questions, for example:
- Where do I place my own .sty or .cls files, to make them available to all my .tex files?
- Including a relative path to a class file
But none of these questions discusses versioned multi-user/platform git repositories. The ideal situation would be that a new member or a member that got a new computer just checks out the repository and can build the documents as long as he has an up-to-date standard TeX distribution. So that the repository is fully self-containing and no tweaking of local PATH
or texmf
stuff is needed for each and every member/computer/operating system – all project-specific configuration should be defined within the git repository.
What are good approaches to such a situation? How to keep the user or per-computer configuration to a minimum and store all build configuration in a central repository?
Best Answer
I assume that you have one Git repository which contains your custom class, but that not every document generated with the class is to be included in the same (or any other) repository, but might exist just as a local copy.
(1) Submitting your class to CTAN
If the class source does not contain any sensitive information, you could upload your class to CTAN. After some time, it will be available in TeXLive/MikTeX distributions and every user that has an up-to-date TeXLive/MikTeX installation can use
\documentclass{ourclass}
. This is particularly useful if the class has reached a certain maturity and is expected to need only low maintenance.(2) Cloning the Git repository multiple times
Usually, class files/folders do not exceed a few hundred kilobytes in size, already including vector image files, custom bibliography styles, etc. So every team member could, after creating a new project folder, call a
git clone
within the specific project folder. Via copies of local repositories and the--reference
option ofgit clone
, network usage could be optimised. Maybe you could supply scripts to your team members that automate and optimise intialcloning
and subsequentpulling
.(3) Project folder structure
(1) and (2) would work without relative paths, which is what you requested. However, changing the folder structure on your team's computers might also be worth considering, e.g.
Then, keep the practise of
\documentclass{../customclass/class}
. This would require to ignore the warnings. If I may add a personal opinion: I did not fully understand why ignoring this specific warning should be problematic.