4

I'm working on experimental packages (say my-package-1 and my-package-2). Their changes are tracked thanks to a version control system (git in fact), the corresponding repositories being as follows:

./
├── doc
│   └── latex
│       └── my-package-⟨n⟩
│           ├── README
│           ├── README.md
│           └── my-package-⟨n⟩.pdf
├── source
│   └── latex
│       └── my-package-⟨n⟩
│           ├── my-package-⟨n⟩.dtx
│           └── my-package-⟨n⟩.ins
└── tex
    └── latex
        └── my-package
            └── my-package-⟨n⟩.sty

Some people are supposed to test these packages and, for convenience, I'd like to avoid them compilations of the .ins and .dtx files: they should be able to use these packages just by cloning in their TEXMFHOME¹ the corresponding git repositories:

git clone ssh://path/to/my-package-⟨n⟩.git

Cloning repositories in $TEXMFHOME/my-package-⟨n⟩/: not a solution

Running these commands from $TEXMFHOME/ directory clones the repositories, not into TEXMFHOME's root, but into $TEXMFHOME/my-package-⟨n⟩/. The problem is, whereas the files:

$TEXMFHOME/tex/latex/my-package-⟨n⟩.sty

would be found by TeX, here the files:

$TEXMFHOME/my-package-⟨n⟩/tex/latex/my-package-⟨n⟩.sty

aren't found by TeX.

Cloning repositories in $TEXMFHOME/: not a solution

Cloning these repositories directly into TEXMFHOME's root is possible by running from $TEXMFHOME/ directory e.g.:

git clone ssh://path/to/my-package-1.git .

Now the problem is that doing the same for the other repository isn't possible:

git clone ssh://path/to/my-package-2.git .

fails with:

fatal: destination path '.' already exists and is not an empty directory.

Cloning repositories in $TEXMFHOME/tex/latex/my-package-⟨n⟩/: a solution but probably not the best one

A workaround would be to run the commands:

git clone ssh://path/to/my-package-⟨n⟩.git

from ad hoc directories, e.g.

$TEXMFHOME/tex/latex/my-package-⟨n⟩/

This would give the following structures:

$TEXMFHOME
└── tex
    └── latex
        └── my-package-⟨n⟩
            ├── doc
            │   └── latex
            │       └── my-package-⟨n⟩
            │           ├── README
            │           ├── README.md
            │           └── my-package-⟨n⟩.pdf
            ├── source
            │   └── latex
            │       └── my-package-⟨n⟩
            │           ├── my-package-⟨n⟩.dtx
            │           └── my-package-⟨n⟩.ins
            └── tex
                └── latex
                    └── my-package
                        └── my-package-⟨n⟩.sty

and, indeed, the files:

$TEXMFHOME/tex/latex/my-package-⟨n⟩/tex/latex/my-package-⟨n⟩.sty

are found by TeX.

But I guess there are better strategies. Hence my question: what would be the strategies for providing packages as version control repositories?


¹ These question is asked with TeX Live distribution in mind but could be adapted to MiKTeX.

  • Are we allowed to suggest symlinks? – Joseph Wright Dec 10 '15 at 15:03
  • @JosephWright Why not? :) – Denis Bitouzé Dec 10 '15 at 15:04
  • 1
    You could provide a Makefile with a installlocal rule. People would git clone or later pull, and then rune make installlocal. (I do this with xint, admittedly there is no clonable repo, but the CTAN contains the suitable Makefile.) However, maybe your users are on various systems. A zip archive is also very convenient unzip foo.zip -d <TEXMF>. – user4686 Dec 10 '15 at 18:48
  • 1
    @jfbu I would like to avoid as many steps as possible and make all the necessary (compiled) files (*.sty, etc.) available with just one command (git clone ...). Moreover, some of the testers are Windows users, probably without Cygwin and hence Makefile could be painful to install. About zip: I would like to avoid this pain to me :) – Denis Bitouzé Dec 10 '15 at 19:41
4

I would suggest not trying to place the main repository into the local TeX tree but rather using appropriate symbolic links (available on Windows at least if one as Admin rights). For testing, the only part of your tree that needs to be visible to TeX is tex, not source or doc (though they could be added). Thus I would have a symbolic link between [HOME]/my-package/tex/latex/my-package and $TEXMFHOME/tex/latex/mypackage. Indeed, I'd probably simplify your structure to [HOME]/my-package/latex/my-package, etc. This will let you do testing on a 'live' version of your code whilst leaving your repository both flexible in terms of structure and placed somewhere more 'natural' for work than inside TEXMFHOME (for example inside some development directory in your main documents directory).

  • 1
    Note that whilst this is what I've got for beamer, that's mainly as I've inherited it from others: I personally prefer to use a script and to install the 'unpacked' version of my code as necessary. – Joseph Wright Dec 10 '15 at 15:11
  • I would let the doc part of the tree visible to TeX in order to increase the probability the testers will read the documentations (texdoc my-package-⟨n⟩) ;) – Denis Bitouzé Dec 10 '15 at 15:55
  • @DenisBitouzé I'd hope people testing and checking out a Git version of your code will also spot that the repository itself has the documentation in it (or indeed it might not: it's a derived file so arguably should not be checked in). – Joseph Wright Dec 10 '15 at 16:12
  • Indeed, but less easy than just typing in a terminal texdoc my-package-⟨n⟩ from any directory. – Denis Bitouzé Dec 10 '15 at 17:15
2

I provided this uninstalled use for class lettre (see lettre project).

You can get the version control (git) work-area of your project in any suitable directory and then add it to the list of TEXMF roots. See lettre manual, §« 1.2 Installation à partir des sources », and for item 3 of the enumerate list, select second bullet.

The cost of having an « uninstalled » package/class is that you cannot recompile easily the manual when the work area has been added to the list of TEXMF roots, because then latex fails to find the source files in the current directory. In the case of lettre I worked around this issue by the makefile detecting this situation and relocating all the sources in a temp directory before compiling the manual.

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.