How to log to stdout from build hooks?

[sneakers-the-rat]

Hello everyone! I don't think this quite justifies an issue and is probably just me missing something when reading the code, but my question is pretty simple - I want to log messages from build hooks to notify the builder of progress (and, ideally, to just pass through stdout from the commands invoked), but can't quite figure out how to do that.

So I have a pretty simple build hook, where i want to build some JS components and bundle them in with my python package. I am just invoking vite as a subprocess, which puts them in package/src/_js

pdm_build.py

from pathlib import Path
from subprocess import run


def pdm_build_hook_enabled(context):
    # Only enable for sdist builds
    return context.target == "sdist"


def pdm_build_initialize(context):
    """Build the js components"""
    
    print('Building JS components') # <-- how to do this???
    
    result = run(['npm', 'run', 'build:package'], cwd=Path(__file__).parents[2] / 'js', capture_output=True)
    if result.returncode != 0:
        raise RuntimeError('JS component build failed! \n' + result.stderr.decode('utf-8'))

    print("JS components built!") # <-- and this???

but no dice, i get just the normal build output

$ pdm build   
Building sdist...
INFO: Inside an active virtualenv ./.venv, reusing it.
Set env var PDM_IGNORE_ACTIVE_VENV to ignore it.
Built sdist at ./dist/noob-1000.0.1+d20260501.tar.gz
Building wheel from sdist...
Built wheel at ./dist/noob-1000.0.1+d20260501-py3-none-any.whl

When what I would like is this

$ pdm build   
Building sdist...
INFO: Inside an active virtualenv ./.venv, reusing it.
Set env var PDM_IGNORE_ACTIVE_VENV to ignore it.
Building JS components
Built JS components
Built sdist at ./dist/noob-1000.0.1+d20260501.tar.gz
Building wheel from sdist...
Built wheel at ./dist/noob-1000.0.1+d20260501-py3-none-any.whl

I was looking through the pdm-core code and saw that it seemed to be using a logger pdm.termui so i also tried that

logger = logging.getLogger('pdm.termui')
logger.info('blah blah blah')

but that also didn't work.

Bonus points would be if i could just have the stdout from the subprocess pass through entirely (just show the vite build output), but i'd settle for just being able to log my own messages.

I see the use of rich as well, but i don't want to just sort of hack around. I figure this is something that would be a general need for anyone using build hooks, so if we come up with some answer i'd be happy to write it up for the hooks docs page.

Thanks in advance everyone!

[Abdeltoto]

TL;DR — Two separate things: (1) your print()s may never reach the terminal because the build backend runs the hook in an isolated subprocess with its own stdio; (2) capture_output=True hides all Vite output by design.

Why you see “no dice”
pdm build → PEP 517 → pdm-backend calls your hook in a controlled environment. Whatever isn’t wired to the installer’s UI often won’t look like normal pdm log lines. Plain print to stdout is the first thing to get lost or buffered there.

Practical fixes

1. Let Vite talk — drop capture_output=True when you don’t need to swallow logs:

   run([...], cwd=..., check=True)  # inherits stdout/stderr → you see Vite

   If you still need to detect failure, use check=True and only capture on error, or stream manually.

2. Try stderr for your own messages — many CLIs show “side” output on stderr:

   import sys
   print("Building JS…", file=sys.stderr, flush=True)

3. More PDM noise when debugging — pdm build -v (or very verbose) often surfaces backend output you’re missing.

4. If you must capture — log to a file under the repo during the hook, or re-raise with result.stderr.decode() in the exception (you already do the latter on failure — good for CI).

If stderr + no capture still shows nothing, it’s worth opening an issue on pdm-backend with a tiny repro: that’s when we’d confirm whether a first-class “reporter” hook exists for progress lines versus errors.

Happy to help turn this into a short doc PR for the hooks page once you settle on a pattern that works for you.

[sneakers-the-rat]

thanks for the reply. i think maybe the purpose of my message might have been lost, i'm looking for some generally prescribed way to put a string in pdm's logging output (since it seems to control stdout). if none exists, then i would be happy to write such a mechanism!

Let Vite talk — drop capture_output=True when you don’t need to swallow logs:

yes, that would be part of the side quest, but i still need to be able to get the output to stdout which is the problem.

Try stderr for your own messages — many CLIs show “side” output on stderr:

does not work, unfortunately, unless i do -v

More PDM noise when debugging — pdm build -v (or very verbose) often surfaces backend output you’re missing.

the goal is to find a supported mechanism for putting strings in stdout without needing to call verbose or otherwise require opt-in, but i can see stdout when i do -v

If you must capture — log to a file under the repo during the hook

i can handle this part! i just need to know how to log to stdout!

If stderr + no capture still shows nothing, it’s worth opening an issue on pdm-backend with a tiny repro:

aha, i had opened this discussion because i wasn't sure if it was a bug or i was just missing something. if this is not something that has been implemented/there is not some way i could access by e.g. snatching the rich console or finding the right logger name, then yes ofc i'd be happy to raise as an issue, just didn't want to be a bother.

[Abdeltoto]

You’re right to separate the two: subprocess output isn’t the same as showing messages in default pdm build output.

As far as I know there isn’t a documented API for piping arbitrary hook strings into PDM’s normal build log without raising verbosity (e.g. -v). If that’s missing, the next step is a focused issue or RFC on pdm-backend/PDM describing the desired behaviour (progress lines from hooks at default log level) — that’s a reasonable engineering ask, not a faux pas.

Thanks for clarifying what you’re aiming for; it makes the gap clearer.