3

I am trying to get PythonTeX 0.15 working with my MiKTeX 2.9 installation, but running into issues. The problem is that when running the batch file from MiKTeX, I get the error ImportError: No module named 'pygments', whereas the exact same command run on the command line works perfectly fine.

Running the .bat file manually from the .tex folder with thesis as its argument works properly also (so, the .bat file itself doesn't seem to be a problem - something about the way MiKTeX is call it?).

.bat file:

pythontex.exe --interpreter "python:py -3" "%1.tex"

command line (run from thesis.tex folder):

pythontex.exe --interpreter "python:py -3" thesis.tex

When running the batch file from within MiKTeX, I get this error message:

E:\School\PATHEDITED>pythontex.exe --interpreter "python:py -3" "thesis.tex" 
Traceback (most recent call last):
File "C:\Users\USERNAME\AppData\Roaming\MiKTeX\2.9\scripts\pythontex\pythontex.py", line 55, in <module>
import pythontex3 as pythontex
File "C:\Users\USERNAME\AppData\Roaming\MiKTeX\2.9\scripts\pythontex\pythontex3.py", line 61, in <module>
from pygments.styles import get_all_styles
ImportError: No module named 'pygments'

So, it appears that PythonTeX seems to think that pygments isn't installed..which is is:

C:\Users\USERNAME>pygmentize --help
Usage: C:\Users\USERNAME\AppData\Local\Programs\Python\Python35-32\Scripts\pygmentize [-l <lexer> | -g] [-F <filter>[:<options>]] [-f <formatter>]
      [-O <options>] [-P <option=value>] [-s] [-v] [-o <outfile>] [<infile>]
[*CHOPPED FOR BREVITY*]

Not sure if this is relevant, but I also have Python 2.7 installed. When installing pygments, I ran pip install pygments but am not sure if it ignored the 2.7 version. What I am thinking is that PythonTex is somehow trying to go after the 2.7 version? No Python 2.7 PATH variables exist, only 3.5...so I'm not sure whether this has any relation to the problem?

If I remove the --interpreter "python:py -3" section of the command, I get the same behavior - .bat breaks, while command line works.

For the life of me, I cannot figure out why this is breaking! I'm hoping either @g-poore or someone else who has worked through this problem can help me identify what is going on here.



For completeness, my .tex document has only these two lines related to PythonTex (and compiles if I remove these lines):

\usepackage{pythontex}

and

\begin{pycode}
print ('Hello, \\LaTeX')
\end{pycode}
  • Quick update: When I run the pythontex.py directly from C:\Users\USERNAME\AppData\Roaming\MiKTeX\2.9\scripts\pythontex in the command line, I get the same error. Seems the .py script is the source of the problem...but I am still rather confused why the .exe file works properly (generates subfolder and py_default_default_0.stdout, pythontex_data.pkl, thesis.pytxmcr, and thesis.pytxpyg files). – whatisit Jan 1 '17 at 2:23
  • Update 2: Copying the .bat file into the same folder as the .tex file and running it with the argument of as the name of the .tex file works also. Therefore, the .bat file and command within appear not to be a problem. – whatisit Jan 1 '17 at 2:58
3

UPDATE: I followed the original method below, but found a better way (for me, at least):

I uninstalled all Python installations completely, then installed Anaconda Python 3.5. Installed the necessary Pygments via pip again. Removed the old Python folder paths in MiKTeX and included the new Anaconda Python installation instead. Everything worked immediately.


ORIGINAL: Turns out, this problem was related to 64-bit and 32-bit path differences.

Pygments is installed in the Python35-32 folder:

C:\Users\USERNAME\AppData\Local\Programs\Python\Python35-32

However, the python executable in the system path and MiKTeX is looking in:

C:\Users\USERNAME\AppData\Local\Programs\Python\Python35

I found two ways to remedy the problem.

  1. Shift everything over to using 32-bit Python (annoying, but Pygments appears to have no 64-bit version? meaning this is the proper way)
  2. Copy the 32-bit Pygments files/folders from the Python35-32 folder to the Python35 folder (Not proper - it won't update/uninstall via pip, but still works)

I actually went with #2 for my own purposes (because it's less work), but I may need to revisit #1, if I find problems related to 32-bit/64-bit incompatibilities.

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.