What is good practice when preparing a package for CTAN?

The CTAN admins don't require compliance to the DTX format at all. Your code and documentation must simply be in a usable form. You should add a short README text file which describes the package well enough so that people can decide if they want install it.

  1. DTX and INS files are not mandatory. You can just include the STY file and a TEX file for the documentation. If you want you can use the sty2dtx script (written by me) to convert a STY file into the DTX format.

  2. You can use any class you want. However, it should still be compilable by other people.

  3. CTAN itself will include documentation without sources, but e.g. TeX Live will not include it as long the source is not freely available ("Free documentation is as important as free software.")

  4. Simply provide a full main file which loads all required packages like for any other LaTeX document. The package and its documentation document are kind of "independent". You should keep package requirements of the manual away from the actual package.

IMHO the large majority of people will simply use the PDF file from CTAN or their used TeX distribution and not try to compile it by themselves. However, people should still be able to do so. Then however, it is OK to not explicitly list all packages again somewhere. A normal formatted LaTeX document with the required \usepackage statements should be just fine. Of course people then need to install the required class and packages when they want to compile the documentation themselves. This is fine as long these are also on CTAN (and best in the main distribution).

There is also now my ctanupload script to automate the uploading process to CTAN.


In addition to what Martin has replied (and I would reiterate the non-requirement of the .dtx format), a very useful utility is Scott Pakin's ctanify script, which packages your stuff into a format specifically designed for upload to CTAN and inclusion into TeXLive. The script works out of the box on Linux and OS X and under Cygwin for Windows.

For example, a fairly simple package or class would likely have the following components:

  • mypackage.sty (the package itself)
  • mypackage.tex (the package documentation source)
  • mypackage.pdf (the compiled package documentation)
  • README (a plain text README file (with no extension))

Using ctanify all I need to do is issue the following command (assuming I'm within the directory of the package):

ctanify --no-tds mypackage.* *.tex=doc README

and this will produce a tar.gz file containing copies of all the files,

By default, ctanify will include a .tds.zip file which contains versions of the files with the .sty file in /tex/latex/mypackage, the documentation in /doc/latex/mypackage. This format is useful for packages with a complex structure. For small packages which contain just a few files, CTAN doesn't recommend a including a .tds.zip file within the tarball so in this example I have added the --no-tds option which prevents the inclusion of the .tds.zip file.

Here's a breakdown of the arguments I gave to the command:

mypackage.* % will automatically deal with .sty, .cls, .pdf, .dtx and .ins
*.tex=doc % put all .tex files into the doc folder
README % include the README file (will go into the /doc folder)

I've just described the simple use. Of course if your package or class has a more complicated set of files, the command would need to be modified appropriately. For example, if you have .tex files that are part of the package itself and not part of the documentation you wouldn't use *.tex but would specify mypackage.tex=doc for the documentation source and a separate specification for the other .tex files.


There is one (minor) issue which might come in handy: choose the name of your documentation file (your pdf) in accordance with your package, i.e. <package>.pdf.

This allows others to call texdoc <package> and the command will launch the appropriate documentation file.

Furthermore, I think the CTAN guys appreciate hints about the format of your submission. For example, it is worth to note whether your .zip file contains a TDS directory structure or simply the files which make up your package - without much of a directory structure.