Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improving the presentation of exceptions within in-process runs #156

Open
pradyunsg opened this issue Nov 18, 2022 · 6 comments
Open

Improving the presentation of exceptions within in-process runs #156

pradyunsg opened this issue Nov 18, 2022 · 6 comments

Comments

@pradyunsg
Copy link
Member

pradyunsg commented Nov 18, 2022

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 pradyunsg changed the title Run subprocess with python -c <shim> rather than python <path-to-in_process.py> Improving the presentation of exceptions within in-process runs Nov 18, 2022
@pradyunsg
Copy link
Member Author

pradyunsg commented Nov 18, 2022

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
Copy link
Member

pfmoore commented Nov 18, 2022

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
Copy link
Member Author

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
Copy link
Member Author

@pfmoore
Copy link
Member

pfmoore commented Nov 18, 2022

🤷 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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants