Forward warning options to subprocess

[abravalheri]

This PR is inspired by the discussions in:

• https://discuss.python.org/t/how-can-build-backends-avoid-breaking-users-when-they-make-backwards-incompatible-changes/85847/49
• https://discuss.python.org/t/how-can-build-backends-avoid-breaking-users-when-they-make-backwards-incompatible-changes/85847/50
• https://discuss.python.org/t/how-can-build-backends-avoid-breaking-users-when-they-make-backwards-incompatible-changes/85847/59

The main idea is to forward whichever warning options have been specified for the "parent" process to the subprocess, as a complement to #157 ¹.

For example, if the user passes python -W ignore -m build, then _in_process.py would also be called with -W ignore.

This is an initial investigation to test the waters, it can be incrementally improved based on feedback.

One thing that I considered is a finer control over the warnings or allowing the API callers to customise the values. But I rejected this idea as over engineering. Based on YAGNI, we can implement something very simple.

Footnotes

1. This way frontends could re-use Python's UI for warning filters without the necessity to implement their own. (They can still implement it if they want, but re-using Python's is handy). ↩

[abravalheri]

/cc @pradyunsg @notatallshaw as this is related to the work in #215.

I think it would actually be interesting to run #215 against the tests in this PR just as a form of regression tests.

[abravalheri]

As a manual sanity check I did the following from my local clone of pyproject-hooks:

cd .nox/
./test-3-10/bin/python -m pip install -U pip
./test-3-10/bin/python -m pip install build -e ..


./test-3-10/bin/python -W ignore -m build ~/workspace/setuptools
# No warnings


./test-3-10/bin/python -W error -m build ~/workspace/setuptools
# ...
#   File "/home/abravalheri/workspace/setuptools/setuptools/warnings.py", line 52, in emit
#    warnings.warn(text, cls, stacklevel=stacklevel + 1)
# setuptools.config.pyprojecttoml._ExperimentalConfiguration: `[tool.distutils]` in `pyproject.toml` is still *experimental* and likely to change in future releases.
#
# ERROR Backend subprocess exited when trying to invoke build_sdist


./test-3-10/bin/python -W default -m build ~/workspace/setuptools
# ... a bunch of things, including:
# WARNING `[tool.distutils]` in `pyproject.toml` is still *experimental* and likely to change in future releases.
# ...

[abravalheri]

Python docs do mention that sys.warnoptions should not be modified but they do not prevent reading it.

In fact, docs for 3.12 even include examples using it for quick checks https://docs.python.org/3.12/library/warnings.html#overriding-the-default-filter:

import sys

if not sys.warnoptions:
    import warnings
    warnings.simplefilter("ignore")

[takluyver]

This makes sense to me, but as I haven't thought much about warnings and @pradyunsg has also worked on the topic in #215, I'd like to hear his view.