gh-133490: Fix syntax highlighting for rem 8000 ote PDB #133494
Conversation
|
Marking as draft until I finish wrestling with getting the tests working on all platforms... |
Security restrictions on some platforms mean we can only attach to our immediate children.
|
So first of all, I'm not sure if we should merge this without approval from @ambv. We introduced some new interface to the colorize system. This is also not how I imagined the integration test should be. Why do we have to make the testing process part of the test? I don't think that makes it easier than juggling with 2 processes. Now that we have passed beta freeze, we don't need to rush into anything. I can work on a prototype and see how that works. Maybe I'm wrong - the integration tests is too fragile and we should do less of it. The current |
Because the Linux buildbots have We could spawn 1 child process and have it spawn a grandchild process that it's allowed to connect to. I tried it, but it was drastically more complicated. If you want to invest in it, though, it is possible, just ugly. |
That makes sense, and that also means pdb attach won't work in such scenario right? In real life. |
Yeah but that is working as expected. Is the same deal with gdb or any other debugger. Including PEP 768 |
Unless you use |
Not really, we are leveraging all the existing theme infrastructure and mirroring the pyrepl APIs. The APIs are also experimental in any case. We can change them if we need after beta 1. I have also reviewed the original change and I can confirm that this is aligned to how is intended to be used. |
|
Yeah I understand that's expected behavior. I meant we are testing a feature on a platform that does not support the feature. |
Not really, is just that the permission model is more restricted. The platform does support the feature and the feature will work if you do it between process on the same process tree. |
What would be a reasonable use case in this scenario? How would user use |
Yeah, the "same tree" thing won't help |
|
And of course the integration tests that I just added rely on the "same tree" thing, by having the tests spawn a subprocess and then call python -m pdb /path/to/script.py |
|
What I meant is - if our buildbot does not provide an environment to support a real life scenario, then it's impossible for us to do reasonable integration test. I guess what we currently have is a compromise, which is not bad at all. I just wonder if we have some way to deal with the environment. |
|
It's not just about the build bots, either. Python's test suite is run by end users and redistributors, so even if the build bots could be set up with an environment with fewer security restrictions for the sake of realistic remote PDB integration tests, you still wouldn't want to rely on that, because it would still not work by default in most end user's Linux systems. |
Do you mean that on most of the end users's Linux system, |
|
Yes, most Linux distros default echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scopeWe should probably explicitly call out how to configure different platforms so that |
Just to insist on this: this applies to the same as any other debugging tool on the system like gdb, strace or anything. It just needs sudo to work as a precaution if the system has yama activated. |
We can skip-news this one, it's a small fix on top of #133491 plus an integration test as @gaogaotiantian requested.
CC @ambv @pablogsal