Skip to content

Let the latexmkrc PythonTeX cus_dep use the configured interpreter - #78

Open
dbosk wants to merge 1 commit into
masterfrom
pythontex-interpreter-from-env
Open

Let the latexmkrc PythonTeX cus_dep use the configured interpreter#78
dbosk wants to merge 1 commit into
masterfrom
pythontex-interpreter-from-env

Conversation

@dbosk

@dbosk dbosk commented Aug 4, 2026

Copy link
Copy Markdown
Owner

Problem

latexmkrc's PythonTeX custom dependency hardcoded its own invocation, so a project that points PythonTeX at a different interpreter was silently ignored whenever latexmk drove the build — latexmk reaches PythonTeX through the cus_dep, not through tex.mk's rule.

This bites exactly the projects that need PythonTeX most: those whose document executes the package it documents, and so must run under a virtualenv interpreter that can import it. Setting

PYTHONTEXFLAGS= --interpreter "python:poetry run python3"

in the project's makefile had no effect on the latexmk path.

53e54b0 had already aligned the cus_dep with tex.mk's default invocation, which fixed portability. But copying a default is not the same as sharing a configuration point — the two paths still diverge the moment anyone overrides it.

The failure is silent and remote from its cause: LaTeX succeeds, latexmk reports the cus_dep as run, and the only symptom is a Python traceback about a missing module several build stages later.

Change

Made in tex.mk.nw; tex.mk and latexmkrc are regenerated.

  • tex.mk now exports PYTHONTEX and PYTHONTEXFLAGS. A latexmkrc is Perl read by a separate process, so it cannot see make's variables — the environment is the one channel that crosses that boundary.
  • The cus_dep reads both back from %ENV, keeping the literal defaults as Perl fallbacks so a hand-run latexmk (no make, empty environment) behaves exactly as before. // rather than || for the flags, so a project can deliberately pass no flags without silently getting the defaults back.

The sub pythontex body moved into its own <<run PythonTeX with the configured interpreter>> chunk, with prose explaining the departure from the CTAN original.

Verification

Against dbosk/ladok3, whose doc build sets PYTHONTEXFLAGS= --interpreter "python:poetry run python3":

before after
ModuleNotFoundError: No module named 'ladok3' 2 0
PythonTeX never ran 0 error(s), 0 warning(s), 58 outputs
make -C doc all Error 12 exit 0
pages 169 (stub) 1438

perl -c latexmkrc passes, and both tangled outputs were diffed against fresh notangle runs.

Note

make latexmkrc in this repo does not tangle — the included tex.mk's latexmkrc: symlink target overrides the Makefile tangle rule, which is #76. I tangled by hand with notangle -R"[[latexmkrc]]" tex.mk.nw | cpif latexmkrc.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QiBv9BVhRKCyYJJNDhiowW

The cus_dep hardcoded its PythonTeX invocation, so a project that points
PythonTeX at a virtualenv interpreter -- the usual case when the document
executes the very package it documents -- was ignored whenever latexmk drove
the build, since latexmk reaches PythonTeX through the cus_dep rather than
through tex.mk's rule. 53e54b0 had aligned the cus_dep with tex.mk's default
invocation, but copying a default is not the same as sharing a configuration
point: the two paths still diverge the moment anyone overrides it.

The failure is silent and remote from its cause. LaTeX succeeds, latexmk
reports the cus_dep as run, and the only symptom is a Python traceback about a
missing module several build stages later.

So export PYTHONTEX and PYTHONTEXFLAGS from tex.mk -- the environment is the
only channel that reaches a latexmkrc, which Perl reads in a separate process
-- and have the cus_dep read them back, keeping the literal defaults as Perl
fallbacks so a hand-run latexmk with no make in the picture behaves as before.
Unset is distinguished from empty so a project can deliberately pass no flags.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QiBv9BVhRKCyYJJNDhiowW
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant