Conversation
a930739 to
f6981c9
Compare
Doc/Makefile
Outdated
| .PHONY: venv-pdf | ||
| venv-pdf: | ||
| @if [ -d $(VENVDIR_PDF) ] ; then \ | ||
| echo "venv-pdf already exists."; \ | ||
| echo "To recreate it, remove it first with \`make clean-venv'."; \ | ||
| else \ | ||
| set -e; \ | ||
| echo "Creating venv in $(VENVDIR_PDF)"; \ | ||
| if $(UV) --version >/dev/null 2>&1; then \ | ||
| $(UV) venv --python=$(PYTHON) $(VENVDIR_PDF); \ | ||
| VIRTUAL_ENV=$(VENVDIR_PDF) $(UV) pip install -r requirements-pdf.txt; \ | ||
| else \ | ||
| $(PYTHON) -m venv $(VENVDIR_PDF); \ | ||
| $(VENVDIR_PDF)/bin/python3 -m pip install --upgrade pip; \ | ||
| $(VENVDIR_PDF)/bin/python3 -m pip install -r requirements-pdf.txt; \ | ||
| fi; \ | ||
| echo "The venv has been created in the $(VENVDIR_PDF) directory"; \ | ||
| fi | ||
|
|
There was a problem hiding this comment.
This is essentially identical to venv, except instead of the REQUIREMENTS variable it hardcodes requirements-pdf.txt.
Can dist-pdf instead invoke venv and set REQUIREMENTS to requirements-pdf.txt?
There was a problem hiding this comment.
Hm, it would be a nice simplification, though after the change two different virtualenvs would share the same location, incorrectly recognising existence of each other.
e.g.
(1) make html -> creates new venv (regular), builds html
(2) then make pdf -> it says venv already exists, therefore we don't rebuild the venv and try to build pdf without extra depenendency
There was a problem hiding this comment.
Oh, sorry, actually I can also set VENVDIR, I will try it tomorrow.
There was a problem hiding this comment.
Implemented in 9cb3ba4. I kept the venv-pdf target and reverted adding the dependency from dist-pdf to venv-pdf, for consequence with other dist- targets. Though I made venv-pdf reuse existing venv target definition.
There was a problem hiding this comment.
(test run after changes: http://github.com/m-aciek/python-docs-offline/actions/runs/22770351164)
There was a problem hiding this comment.
Thanks, looks much better!
I'm wondering if we even need two named venvs.
Right now you can do:
(1) make html -> usual html build
(2) then make htmllive -> will also install the extra sphinx-autobuild dependency
Similarly for (3) make check -> installs pre-commit
Can we follow the same pattern?
There was a problem hiding this comment.
Thank you for catching that! Suggested approach is even more minimal. Implemented in 4b90701. I don't think we need to pin the package version as long as PDF build is not included in CPython's CI (otherwise I'd do it, for reproducible builds).
| :align: center | ||
| :width: 100% | ||
|
|
||
| Live mode displays real-time profiling statistics, showing combined |
| :alt: Tachyon live mode with opcode panel | ||
| :align: center | ||
| :width: 100% | ||
| .. only:: not latex |
…svg2pdfconverter Makefile target


Fix PDF build of documentation.
sphinxcontrib.rsvgconverterfrom the package for converting of SVG graphics to PDF format.Refs. python/docs-community#182.
Test build is available here: http://github.com/m-aciek/python-docs-offline/actions/runs/22771888107. Artifacts include ZIP to download.
For the reference, problematic docs lines:
cpython/Doc/library/heapq.rst
Line 348 in 852ec18
cpython/Doc/library/datetime.rst
Line 157 in d3b6faf
cpython/Doc/library/profiling.sampling.rst
Line 1197 in 37430ca
cpython/Doc/library/profiling.sampling.rst
Line 1220 in 37430ca
📚 Documentation preview 📚: https://cpython-previews--145480.org.readthedocs.build/