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

Debugpy subsystem doesn't use interpreter constraints #17672

Closed
CJTurpie opened this issue Nov 29, 2022 · 1 comment · Fixed by #17678
Closed

Debugpy subsystem doesn't use interpreter constraints #17672

CJTurpie opened this issue Nov 29, 2022 · 1 comment · Fixed by #17678
Assignees
Labels
backend: Python Python backend-related issues bug

Comments

@CJTurpie
Copy link

Describe the bug
I’m trying to set up debugging (for the test and run goals) in VSCode. I’m running pants 2.14 on an M1 mac with Python 3.9. When I try to run ./pants test --debug-adapter <path to test file> I get the following error:

15:06:23.64 [INFO] Completed: Building pytest_runner.pex
15:06:23.64 [ERROR] 1 Exception encountered:

  ProcessExecutionFailure: Process 'Building pytest_runner.pex' failed with exit code 1.
stdout:

stderr:
A distribution for debugpy could not be resolved for ~/.pyenv/versions/3.9.15/bin/python3.9.
Found 1 distribution for debugpy that do not apply:
1.) The wheel tags for debugpy 1.6.0 are cp38-cp38-macosx_10_15_x86_64 which do not match the supported tags of ~/.pyenv/versions/3.9.15/bin/python3.9:
cp39-cp39-macosx_13_0_arm64
... 409 more ...

@jsirois suggest on the slack the following:

[The error message above] refers not to resolving dependencies from the internet, but resolving them from a built PEX. In other words, the PEX file contains only Python 3.8 debugpy, but the PEX was launched with Python 3.9; so no dice. Towards that end, from a quick read of code, it looks like the debugpy subsystem, although it supports ICs, is requested without them:

debugpy_pex = await Get(Pex, PexRequest, debugpy.to_pex_request())

I think that means maybe the ambient interpreter running Pants (3.9 in your case?), is what gets used to build that Pex. And that does not match the test batch in question which uses 3.8.

Pants version
2.14

OS
MacOS - M1

Additional info
n/a

@thejcannon
Copy link
Member

I can reproduce this in Pants' codebase by installing Py3.8 and Py3.9. ./pants will choose 3.8. Then run a test with ICs set to ==3.9.*.

Then:

A distribution for debugpy could not be resolved for /usr/bin/python3.9.
Found 1 distribution for debugpy that do not apply:
1.) The wheel tags for debugpy 1.6.0 are cp38-cp38-manylinux1_x86_64, cp38-cp38-manylinux_2_12_x86_64, cp38-cp38-manylinux2010_x86_64, cp38-cp38-manylinux_2_5_x86_64 which do not match the supported tags of /usr/bin/python3.9:
cp39-cp39-manylinux_2_31_x86_64
... 661 more ...

@thejcannon thejcannon added the backend: Python Python backend-related issues label Dec 3, 2022
thejcannon added a commit that referenced this issue Dec 8, 2022
Fixes #17672 and fixes #17692

Added new test-code which tests the `DebugAdapterRequest` by running it without `--wait-for-client`. This wouldn't catch issues like #17540 which require a client, but would catches issues like #17672 and #17692.

Fixes:
- Bad debugpy ICs
- Untracked issue where the process would always return 0
- The config wouldn't be used if provided
- Removes the reliance on `importlib_metadata` to load the entrypoint, instead re-enters the already executing pex in-process
thejcannon added a commit to thejcannon/pants that referenced this issue Dec 9, 2022
Fixes pantsbuild#17672 and fixes pantsbuild#17692

Added new test-code which tests the `DebugAdapterRequest` by running it without `--wait-for-client`. This wouldn't catch issues like pantsbuild#17540 which require a client, but would catches issues like pantsbuild#17672 and pantsbuild#17692.

Fixes:
- Bad debugpy ICs
- Untracked issue where the process would always return 0
- The config wouldn't be used if provided
- Removes the reliance on `importlib_metadata` to load the entrypoint, instead re-enters the already executing pex in-process
thejcannon added a commit that referenced this issue Dec 10, 2022
…17768)

Fixes #17672 and fixes #17692

Added new test-code which tests the `DebugAdapterRequest` by running it without `--wait-for-client`. This wouldn't catch issues like #17540 which require a client, but would catches issues like #17672 and #17692.

Fixes:
- Bad debugpy ICs
- Untracked issue where the process would always return 0
- The config wouldn't be used if provided
- Removes the reliance on `importlib_metadata` to load the entrypoint, instead re-enters the already executing pex in-process
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend: Python Python backend-related issues bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants