# Conflict in the Key Values in Nested Tikz Enviroments

I am developing some Tikz commands with pgfkeys, and I want to use the commands that I developed earlier in my new commands. This creates nested Tikz and Tikz math enviroments as shown in the MWE given below.

Without changing the variable names, how can I pass the correct value of \a in the second call to the \testing, which is 3, not 4? I think in the MWE, the name \b is passed to the command, not 3.

The reason I am asking this question is I do not want to know the key variables used in the command \testing for a better coding.

\documentclass[]{standalone}
\usepackage{tikz}
\usetikzlibrary{math}

\pgfkeys{
/testing/.is family,
/testing,
b/.store in =\b,
a/.store in =\a}

\newcommand{\testing}[1][]{\pgfkeys{/testing, #1}
\tikzmath{
real \a, \b;
print ($Out:$);
print ($a = \a,$);
print ($b = \b |$);
}}

\begin{document}
\begin{tikzpicture}
\tikzmath{\b = 3;}
\path(0,-0.5) -- (6,0.5);
\testing[a = 1, b = 2]     %Result: a = 1, b = 2
\testing[a = \b, b = 4]    %Result: a = 4, b = 4. Should be: a = 3, b = 4.
\end{tikzpicture}
\end{document}


• Don't nest tikzpicture environments. It is unsupported. In very simple cases, it may happen to work. But, if it does, that's just luck and it is liable to break at any time. – cfr Jun 28 '17 at 11:10
• I am trying to develop a package with many custom commands in it. Each command uses the structure shown above. The problem occured when I was developing a new command and had to call another command I had already written. Seems like I have to make all keys private to avoid the conflict, or this is not a common way of developing packages? – berkus Jun 28 '17 at 11:11
• to be honest, it is very unclear to me what you are trying to accomplish, from the MWE. Can you give an explanation of why you are expecting 3,4? – Bordaigorl Jun 28 '17 at 11:13
• It is not common practice to use the same name for multiple things in a package, no. Also, it would be better to use package specific names and avoid single letter macros. For the immediate problem, you can try .estore in, but I really wouldn't do it this way. – cfr Jun 28 '17 at 11:14
• I was going to suggest .estore in too but I agree with @cfr that this looks wrong. Also, consider that these are local definitions, so if you wrap groups around them you may be able to control their scope better. – Bordaigorl Jun 28 '17 at 11:16