Show debug information about backend #969

abitrolly · 2025-12-26T07:31:52Z

When reporting underlying backend (setuptools) issues, the (setuptools) tracker requirement is to mention exact version of backend being used. This information is, however, absent from the build output.

This PR shows backed spec being used, without version:

$ touch pyproject.toml
$ python -m build
* Creating isolated environment: venv+pip... build:backend  setuptools.build_meta:__legacy__ build:python_executable  /tmp/build-env-098a9c2b/bin/python
* Installing packages in isolated environment:
  - setuptools >= 40.8.0 ...

Getting version requires running custom code in venv created by build after backend is installed and it is not clear how to do that yet. The code should extract first component from the spec, and append __version__ to it. At least that's the way of doing it for setuptools.

Fixes #959

When reporting underlying backend (setuptools) issues, the (setuptools) tracker requirement is to mention exact version of backend being used. This information is, however, absent from the `build` output. This commmit shows backed spec being used, without version: $ touch pyproject.toml $ python -m build * Creating isolated environment: venv+pip... build:backend setuptools.build_meta:__legacy__ build:python_executable /tmp/build-env-098a9c2b/bin/python * Installing packages in isolated environment: - setuptools >= 40.8.0 ... Getting version requires running custom code in venv created by `build` after backend is installed and it is not clear how to do that yet. The code should extract first component from the spec, and append `__version__` to it. At least that's the way of doing it for `setuptools`. Related to pypa#959

abitrolly · 2025-12-26T08:21:51Z

JSON tests fail, because the debug output is unconditional,

There is some kind of logging framework in _ctx.py, obscured by "contextvars" and types https://github.com/pypa/build/blob/a40623b20de5d29c80b569283191d65e630f4fc0/src/build/_ctx.py

I couldn't make it work yet. Looks like verbosity is manually controlled, and there is a sole method log that only outputs INFO level messages.

build/src/build/_ctx.py

Line 23 in a40623b

_default_logger.log(logging.INFO, message, stacklevel=2)

layday

This should all probably be done in __main__, using _ctx.log with an origin.

$ python -m build -v * Creating isolated environment: venv+pip... build:backend setuptools.build_meta:__legacy__ build:python_executable /tmp/build-env-5yw5g814/bin/python ...

abitrolly · 2025-12-31T03:19:33Z

@layday made it to use _ctx.log. Still need to investigate how to run a command inside build venv.

Also report backend lib name together with version

Also strip newline from the version

abitrolly · 2026-01-01T21:09:07Z

Marking this as ready for review. Need to make sure that this output is acceptable before patching tests.

$ touch pyproject.toml
$ python -m build
...
* Building wheel...
  (using setuptools 80.9.0)
running bdist_wheel

layday · 2026-01-01T21:36:02Z

src/build/_builder.py

+        lib = self._backend.split('.')[0]
+        script = f'import {lib}; print({lib}.__version__)'
+        cmd = [self.python_executable, '-c', script]


You should use importlib.metadata.version (via _compat) with the dist name. A mapping of module to dist names is provided by importlib.metadata.packages_distributions. It'd be easier to just list the installed versions of all direct dependencies, though.

@layday _compat is unavailable inside venv. Is there any way to get it there?

@layday I copied the _compat.importlib logic into script. That was the most straightforward solution.

@layday I got the dist name from the module name through packages_distributions.

module = self._backend.split('.')[0] script = textwrap.dedent(f""" import sys try: from importlib import metadata except ModuleNotFoundError: # Python < (3, 10, 2) import importlib_metadata as metadata lib = metadata.packages_distributions()['{module}'][0 ] print(lib + ' ' + metadata.version(lib)) """)

List direct dependencies from builder.build_system_requires should be possible too.

Changed the logic to print build requirements. Now the output is more suitable for reproduction.

* Building wheel... setuptools==80.9.0

@layday purelib code doesn't work with path.

$ cd /tmp $ python -m venv xxx $ ls /tmp/xxx/lib/python3.13/site-packages pip pip-24.3.1.dist-info $ python

>>> from importlib.metadata import distributions >>> next(iter(distributions(name="pip"))).version '24.3.1' >>> next(iter(distributions(name="pip", path="/tmp/xxx/lib/python3.13/site-packages"))).version Traceback (most recent call last): File "<python-input-2>", line 1, in <module> next(iter(distributions(name="pip", path="/tmp/xxx/lib/python3.13/site-packages"))).version ~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ StopIteration >>>

For my runs _has_dependency is only called with empty kwargs, so maybe the purelib codepath is dead.

What to do now?

The path is a list[str].

@layday thanks. It works now. I had to pass env to the builder though.

@layday it is done now, but tests are failing, and I don't get what is going on. If I run test_projectbuilder.py test_log scenario manually, it gives this.

$ cd tests/packages/test-flit $ PYTHONPATH=../../../src python -m build * Creating isolated environment: venv+pip... * Installing packages in isolated environment: - flit_core >=2,<4 * Getting build dependencies for sdist... * Building sdist... flit_core==3.12.0 * Building wheel from sdist * Creating isolated environment: venv+pip... * Installing packages in isolated environment: - flit_core >=2,<4 * Getting build dependencies for wheel... * Building wheel... flit_core==3.12.0 Successfully built test_flit-1.0.0.tar.gz and test_flit-1.0.0-py2.py3-none-any.whl

But fixed test is missing all previous lines https://github.com/pypa/build/actions/runs/20720516961/job/59482742587?pr=969

E Full diff: E [ E - ( E - 'INFO', E - 'Getting build dependencies for sdist...', E - ), E - ( E - 'INFO', E - 'Getting build dependencies for wheel...', E - ), E - ( E - 'INFO', E - 'Getting metadata for wheel...', E - ), E - ( E - 'INFO', E - 'Building sdist...', E - ), E ( E 'INFO', E ' flit_core==3.12.0', E ), E ( E 'INFO', E - 'Building wheel...', E - ), E - ( E - 'INFO', E ' flit_core==3.12.0', E ), E ]

@layday the problem was that tests use default logger, which was skipping messages with origin. I addressed that, but also left some proposals for enhancements in #973

The only problem I can not solve with testing is how to mock package installation in tests/test_main.py::test_logging_output. For some asserts it uses ' setuptools==42.0.0' and for some 'setuptools==80.9.0'. I am not sure if the latest version line wouldn't drift if I add it to assert.

It is easier and more informative than detecting package from backend module name.

abitrolly · 2026-01-02T09:21:25Z

Instead of detecting build backend module from its import path, then package name from the module name and then version from from package, just list installed versions of all build requirements.

* Building wheel...
    setuptools==80.9.0
```

importlib discovery API takes optional path to site-packages, so it is possible to query versios of packages inside venv installation without activating it first. To pass purelib_dir to builder (so that it can query the versions of installed build backend packages for debugging), the path saved in env backend (pip or uv class), and then env reference is passed and saved in the builder.

Otherwise this API was only available in venv

This adds semantic to logging and decouples log messages

Default logger used in tests ignored origin

Tests use default logger that doesn't understand verbosity

abitrolly mentioned this pull request Dec 26, 2025

Show build backend and backend commands in verbosity mode #959

Open

layday requested changes Dec 26, 2025

View reviewed changes

Use _ctx.log from __main__.py for debug output

c37eb9b

$ python -m build -v * Creating isolated environment: venv+pip... build:backend setuptools.build_meta:__legacy__ build:python_executable /tmp/build-env-5yw5g814/bin/python ...

abitrolly force-pushed the debug-backend branch from b2a9452 to c37eb9b Compare December 31, 2025 02:49

abitrolly added 6 commits January 1, 2026 13:34

Show build backend version in verbose mode

d75dc65

Do not crash if backend info is unavailable

e14d4e2

Also report backend lib name together with version

Fix EncodingWarning: 'encoding' argument not specified

00ab400

Show backend version after build starts

7c0ab07

Also strip newline from the version

Show backend version in default verbosity

3cdf442

Use 'debug' origin for diagnostic in verbose mode

01d1f60

abitrolly marked this pull request as ready for review January 1, 2026 21:09

abitrolly requested review from FFY00, gaborbernat and henryiii as code owners January 1, 2026 21:09

layday reviewed Jan 1, 2026

View reviewed changes

abitrolly added 3 commits January 2, 2026 10:50

Use importlib to query backend version in build venv

1ddda94

Use packages_distributions to get package name from module

1073b21

Print versions for all build requirements

be6e91f

It is easier and more informative than detecting package from backend module name.

abitrolly requested a review from layday January 2, 2026 09:22

abitrolly force-pushed the debug-backend branch from 14bbc11 to 0f66be8 Compare January 5, 2026 09:41

abitrolly added 3 commits January 5, 2026 14:27

Add BaseEnv to query build dependency in system environment

0f3044d

Otherwise this API was only available in venv

Add step origin to logging messages with *

69ffd50

This adds semantic to logging and decouples log messages

Trying to fix tests by mocking query for installed packages

93001fa

abitrolly force-pushed the debug-backend branch from d53654c to 93001fa Compare January 5, 2026 15:39

abitrolly added 2 commits January 6, 2026 06:34

Fix tests after letting default logger print all messages

f67bf83

Default logger used in tests ignored origin

Fix projectbuilder log test

ad5c32d

Tests use default logger that doesn't understand verbosity

abitrolly force-pushed the debug-backend branch from deea5f2 to ad5c32d Compare January 6, 2026 07:02

Show debug information about backend #969

Are you sure you want to change the base?

Show debug information about backend #969

Conversation

abitrolly commented Dec 26, 2025

Uh oh!

abitrolly commented Dec 26, 2025

Uh oh!

layday left a comment

Choose a reason for hiding this comment

Uh oh!

abitrolly commented Dec 31, 2025

Uh oh!

abitrolly commented Jan 1, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

abitrolly commented Jan 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants