Open pradyunsg opened 1 year ago
FWIW, I wouldn't mind if alternatively we rewrote the exception's traceback before re-raising it to be something like:
Traceback (most recent call last):
File "<pyproject-hooks-runner>", line 118, in get_requires_for_build_wheel
File "/private/var/folders/y1/j465wvf92vs938kmgqh63bj80000gn/T/pip-build-env-g800knhv/overlay/lib/python3.10/site-packages/setuptools/build_meta.py", line 338, in get_requires_for_build_wheel
return self._get_build_requires(config_settings, requirements=['wheel'])
[blah blah]
That won't require a reworking of our subprocess invocation mechanism and instead be a code-only change within in_process.py.
This might also help with https://github.com/pypa/pyproject-hooks/issues/148, assuming we treat the current in_process code as "data" within the package (which is a reasonable thing to do).
However, #148 appeared to have a problem with the file being named as *.py
, which I don't think we should change even if we treat it as data, because that allows tools to do things like syntax highlight the code. (IIRC, it was you who pointed out this benefit to me in the past 😉)
because that allows tools to do things like syntax highlight the code. (IIRC, it was you who pointed out this benefit to me in the past 😉)
Well, most tools that I use nowadays are smart enough to recognise shebangs to syntax highlight things correctly + gimme code completion and all that fun stuff. :)
FWIW, here's a link to the somewhat-extensive shim that pip uses: https://github.com/pypa/pip/blob/ba0e3ac6f4f0f396c02ae248c599205b98d184aa/src/pip/_internal/utils/setuptools_build.py#L8
🤷 Honestly, I don't care that much. I've just seen people ask for this type of change in both directions (on various projects), which suggests to me that there's no strong arguments in either direction (and so generally "status quo wins" in my mind).
Well, you and I are in the same camp then. :)
One of the things I'm thinking of (but haven't actioned on in any way, so far) is adopting something similar to pip's setuptools shim in this project. With that, we'd basically be passing the runner-code as a string and calling it within an
exec()
call within a runner shim.Basically, that changes the tracebacks from...
to:
This might also help with #148, assuming we treat the current
in_process
code as "data" within the package (which is a reasonable thing to do).