4

I was reading about creating coordinate systems in the pgfmanual and was surprised to see the use of \define@key in one of the examples

\makeatletter
\define@key{cylindricalkeys}{angle}{\def\myangle{#1}}
\define@key{cylindricalkeys}{radius}{\def\myradius{#1}}
\define@key{cylindricalkeys}{z}{\def\myz{#1}}
\tikzdeclarecoordinatesystem{cylindrical}%
{%
\setkeys{cylindricalkeys}{#1}%
\pgfpointadd{\pgfpointxyz{0}{0}{\myz}}{\pgfpointpolarxy{\myangle}{\myradius}}
}
\begin{tikzpicture}[z=0.2pt]
\draw [->] (0,0,0) -- (0,0,350);
\foreach \num in {0,10,...,350}
\fill (cylindrical cs:angle=\num,radius=1,z=\num) circle (1pt);
\end{tikzpicture}

I copied and pasted this into a document whose class was article and only loaded one package, tikz. Everything compiled fine.

So I added a line to list the files:

\documentclass{article}
\usepackage{tikz}
\listfiles
\begin{document}

\makeatletter
\define@key{cylindricalkeys}{angle}{\def\myangle{#1}}
\define@key{cylindricalkeys}{radius}{\def\myradius{#1}}
\define@key{cylindricalkeys}{z}{\def\myz{#1}}
\tikzdeclarecoordinatesystem{cylindrical}%
{%
\setkeys{cylindricalkeys}{#1}%
\pgfpointadd{\pgfpointxyz{0}{0}{\myz}}{\pgfpointpolarxy{\myangle}{\myradius}}
}
\begin{tikzpicture}[z=0.2pt]
\draw [->] (0,0,0) -- (0,0,350);
\foreach \num in {0,10,...,350}
\fill (cylindrical cs:angle=\num,radius=1,z=\num) circle (1pt);
\end{tikzpicture}

\end{document}

I discovered that the following key value packages loaded:

  keyval.sty    1999/03/16 v1.13 key=value parser (DPC)
 pgfkeys.sty    
 pgfkeys.code.tex
kvdefinekeys.sty    2011/04/07 v1.3 Define keys (HO)
kvsetkeys.sty    2012/04/25 v1.16 Key value parser (HO)

I assumed (rather incorrectly, apparently) that it was the pgfkeys package loading these dependencies. But, when I made a document which only used pgfkeys, the listed files were only:

 *File List*
 article.cls    2007/10/19 v1.4h Standard LaTeX document class
  size10.clo    2007/10/19 v1.4h Standard LaTeX file (size option)
 pgfkeys.sty    
 pgfkeys.code.tex
 ***********

I could continue in this manner of loading only one package at a time and listing its package dependencies. But that's rather tedious. Is there in general a less tedious way to better discover how the various packages are depending upon one another?

Note: I'm not asking just about tikz or pgf. It was only via playing with those two packages that this question arose.

Update

It looks like How to design a command inquiring internally required packages? provides something of a solution. Though the answer provided @HeikoOberdiek only seems to list the dependencies the first time they're encountered. If a subsequent packages requires a package that has already been required, then it's not printed out a second time.

Community
  • 1
A.Ellett
  • 50,533
  • 1
    Is there a specific reason you need to know? Provided a package correctly loads its own dependencies, there should be no issues. – Joseph Wright Apr 12 '14 at 14:45
  • tikz.sty requires pgf.sty which requires pgfcore.sty which requires keyval.sty. Not easy to follow. The packages in the oberdiek bundle do something similar. – egreg Apr 12 '14 at 14:49
  • 1
    @JosephWright I guess I could be concerned with name conflicts. But, in general, this is really a curiosity question. – A.Ellett Apr 12 '14 at 14:51
  • You could redefine \usepackage, \RequirePackage, etc. to keep track of what loads what and save that information in a first pass, and produce some directed graph of dependencies between class/packages in a second pass, couldn't you? That would actually be a nice package. – jub0bs Apr 12 '14 at 14:53
  • @egreg That's what I was able to figure out, but what I'm wondering is, without opening each .sty or .code.tex file and doing a file chanse, is there a more direct way provided to track down such chains of dependencies. (Again, this isn't really a question about tikz or pgf per se. They just happen to be large packages.) – A.Ellett Apr 12 '14 at 14:53
  • 2
    Perhaps the answers to How to design a command inquiring internally required packages? could be of interest for you. – Gonzalo Medina Apr 12 '14 at 14:54
  • There is an answer here on tex.sx, i think bei Heiko Oberdiek producing some kind of loading tree in the log. But i can't find it. – Johannes_B Apr 12 '14 at 14:54
  • @Jubobs That's a great idea. Hmm. Too bad I hadn't thought of that. How about posting such an answer? – A.Ellett Apr 12 '14 at 14:54
  • @GonzaloMedina That was exactly what i meant. :-) – Johannes_B Apr 12 '14 at 14:55
  • @A.Ellett Well, it's just a suggestion. I don't have enough time to pursue that possibility, so I don't think it would be right to post it as an answer. – jub0bs Apr 12 '14 at 14:56
  • @A.Ellett if you consider that the answers there are in fact an answer to your question, then yes, I think this could be marked as a duplicate. – Gonzalo Medina Apr 12 '14 at 14:58
  • @A.Ellett Then, I guess we could mark it as duplicate if you agree. – Gonzalo Medina Apr 12 '14 at 15:10
  • I've started the "close" voting process. – A.Ellett Apr 12 '14 at 15:16

0 Answers0