Why did Poetry not surface the deprecation errors from setuptools?

[fixermark]

A change to setuptools yesterday broke myriad builds around the globe. One such breakage was alembic_utils installed via poetry.

One confusing aspect of the entire situation is that setuptools has been emitting a warning about using a hyphenated key (in the case of alembic_utils, description-file) since 2021, but that warning has never surfaced in our poetry install.

Is there a config to surface setuptools warnings during poetry install? I'm unable to find one in https://python-poetry.org/docs/main/.

[Secrus]

There is no standard mechanism for backends to communicate warnings/errors (except for hard errors that fail the process) with frontends like Poetry.

[fixermark]

This is confusing to me; I'd have assumed that backend communication channel would be stdout and stderr.

We don't need Poetry to take action on our behalf related to output from setuptools; we just need to be able to see it.

[radoering]

IIRC, we capture stdout/stderr and only print it if there is an error. It might make sense to print it in verbose mode. However, you also have to consider that an sdist is only build once and cached afterwards so that you will only get warnings on the first run anyway.

If someone is interested in taking a deeper look, a good starting point might be

poetry/src/poetry/utils/isolated_build.py

Lines 192 to 209 in 2950bd6

	stdout = StringIO()
	try:
	builder = ProjectBuilder.from_isolated_env(
	env, source, runner=quiet_subprocess_runner
	)
	with redirect_stdout(stdout):
	env.install(builder.build_system_requires)
	# we repeat the build system requirements to avoid poetry installer from removing them
	env.install(
	builder.build_system_requires
	| builder.get_requires_for_build(distribution)
	)
	yield builder
	except BuildBackendException as e:
	raise IsolatedBuildBackendError(source, e) from None

[fixermark]

Thank you! I'll take a look and see if there's a verbose-mode option I missed (or if one could be added).

Caching isn't an issue for us; we're usually doing builds of our dependencies from empty environments using a Jenkins CI pipeline. The issue I'm chasing that we need to be able to see transitive messages to be able to take responsibility for our whole build chain.