pypa/pyproject-hooks

Improving the presentation of exceptions within in-process runs

pradyunsg opened this issue · 6 comments

pradyunsg commented

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 commented

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.

pfmoore commented

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

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

pradyunsg commented

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

pfmoore commented

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

pradyunsg commented

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