-
Notifications
You must be signed in to change notification settings - Fork 146
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
Allow using pydevd as a regular dependency. #1586
base: main
Are you sure you want to change the base?
Allow using pydevd as a regular dependency. #1586
Conversation
@nicolas-graves please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
7709b5d
to
9543d56
Compare
Hi, what's the status on this? |
I suppose it should be okay as long as all of the tests pass. |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Tests are flakey right now so it's rather hard to tell. |
This change may not be necessary anymore as well as we've updated our pydevd rather recently |
I think we could actually just switch to use a git submodule and then pydevd changes would just end up here automatically. |
Looks like a new dependency was added? I'm not sure why tox is failing. |
That would be great. :) Sounds like the way to go. @nicolas-graves Would you like to update your branch adding that git submodule? |
@rchiodo pydevd can be built as a distinct package. This pull request is about using that distinctly packaged pydevd, instead of bundling its sources directly within debugpy. Using a git submodule would not address the use case here; it would simply change the way pydevd is bundled within the project (still better than checking in source code from another project, but not the same as what is proposed here). |
I thought the reason for this was because pydevd wasn't being kept up to date. Are you saying you'd also want other versions of pydevd? |
No, the reason was to have a single pydevd package offered by the distribution that can be used by other users (software), as a normal library would. The policy of using the least amount of bundled libraries is used for example in Debian and GNU Guix, among other GNU/Linux distributions, as it means updates and bug fixes can be applied to a single place. It's also more efficient (disk and compute wise). |
be17dd6
to
65710cf
Compare
The way |
65710cf
to
f44cf65
Compare
@nicolas-graves Thank you for keeping this PR up-to-date! |
/azp run |
Azure Pipelines could not run because the pipeline triggers exclude this branch/path. |
Okay for some reason our pipeline was locked down. We're trying to figure out why. |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
All of the tests are failing with this here:
You should be able to reproduce test failures locally following the directions in the CONTRIBUTING.md about running tests. |
Actually I use pytest on Guix and it works well, bundled or unbundled. I'm going to have to go with little touches and iterations and your pipeline, because tox is difficult to use properly using GNU Guix. Here's a first light iteration to try and define pydevd_constants after importing |
f44cf65
to
c9edf76
Compare
/azp run |
Commenter does not have sufficient privileges for PR 1586 in repo microsoft/debugpy |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
@rchiodo Are you sure the failures come from my changes? I indeed see some failures, but at least some of them seem unrelated to what I've done here. Things like: |
That connection reset may be a side effect of the process dying (it's not the error, but the output from when the error occurs). It looks like all of the attach tests are failing. Do they fail locally for you too? |
I can run them with pytest in a sandboxed environment without issues. (Currently only tested with GNU Guix/pytest@7/[email protected]). |
These are the tests that are consistently failing through all of those examples:
So it looks like something in this code is breaking subprocess debugging. |
This reopens #902
The new commit is rebased, builds on @Apteryks commit, and addresses the points in the review.