pyproject-hooks icon indicating copy to clipboard operation
pyproject-hooks copied to clipboard

Improving the presentation of exceptions within in-process runs

Open pradyunsg opened this issue 1 year ago • 6 comments

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...

Traceback (most recent call last):
  File "/Users/pradyunsg/Developer/github/pip/src/pip/_vendor/pep517/in_process/_in_process.py", line 351, in <module>
    main()
  File "/Users/pradyunsg/Developer/github/pip/src/pip/_vendor/pep517/in_process/_in_process.py", line 333, in main
    json_out['return_val'] = hook(**hook_input['kwargs'])
  File "/Users/pradyunsg/Developer/github/pip/src/pip/_vendor/pep517/in_process/_in_process.py", line 118, in get_requires_for_build_wheel
    return hook(config_settings)
  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]

to:

Traceback (most recent call last):
  File "<string>", line 2, in <module>
  File "<pyproject-hooks-runner>", line 351, in <module>
    main()
  File "<pyproject-hooks-runner>", line 333, in main
    json_out['return_val'] = hook(**hook_input['kwargs'])
  File "<pyproject-hooks-runner>", line 118, in get_requires_for_build_wheel
    return hook(config_settings)
  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]

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).

pradyunsg avatar Nov 18 '22 12:11 pradyunsg

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.

pradyunsg avatar Nov 18 '22 12:11 pradyunsg

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 😉)

pfmoore avatar Nov 18 '22 13:11 pfmoore

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. :)

pradyunsg avatar Nov 18 '22 13:11 pradyunsg

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

pradyunsg avatar Nov 18 '22 13:11 pradyunsg

🤷 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).

pfmoore avatar Nov 18 '22 14:11 pfmoore

Well, you and I are in the same camp then. :)

pradyunsg avatar Nov 18 '22 14:11 pradyunsg