[lldb-dev] [RFC]The future of pexpect

[Pavel Labath via lldb-dev]

On 31/01/2019 02:32, Davide Italiano via lldb-dev wrote:
> As you probably know (I didn’t), lldb embeds its own version of
> `pexpect-2.4`, which doesn’t support python3.
> This is the (relatively short) list of tests relying on pyexpect:
> 
> testcases/tools/lldb-mi/syntax/TestMiSyntax.py:        import pexpect
>                          # 7 (EOF)
> testcases/tools/lldb-mi/lldbmi_testcase.py:        import pexpect
> testcases/tools/lldb-mi/signal/TestMiSignal.py:        import pexpect
> testcases/tools/lldb-mi/signal/TestMiSignal.py:        import pexpect
> testcases/lldbtest.py:            import pexpect
> testcases/driver/batch_mode/TestBatchMode.py:        import pexpect
> testcases/driver/batch_mode/TestBatchMode.py:        import pexpect
> testcases/driver/batch_mode/TestBatchMode.py:        import pexpect
> testcases/driver/batch_mode/TestBatchMode.py:        import pexpect
> testcases/lldbpexpect.py:    import pexpect
> testcases/terminal/TestSTTYBeforeAndAfter.py:        import pexpect
> testcases/darwin_log.py:        import pexpect
> testcases/macosx/nslog/TestDarwinNSLogOutput.py:        import pexpect
> testcases/benchmarks/stepping/TestSteppingSpeed.py:        import pexpect
> testcases/benchmarks/frame_variable/TestFrameVariableResponse.py:
>    import pexpect
> testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py:
>         import pexpect
> testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py:
>         import pexpect
> testcases/benchmarks/expression/TestExpressionCmd.py:        import pexpect
> testcases/benchmarks/expression/TestRepeatedExprs.py:        import pexpect
> testcases/benchmarks/expression/TestRepeatedExprs.py:        import pexpect
> testcases/benchmarks/startup/TestStartupDelays.py:        import pexpect
> testcases/functionalities/command_regex/TestCommandRegex.py:
> import pexpect
> testcases/functionalities/single-quote-in-filename-to-lldb/TestSingleQuoteInFilename.py:
>         import pexpect
> testcases/functionalities/format/TestFormats.py:        import pexpect
> 
> (I count 14, but there might be something else).
> 
> I audited all of them and from what I see they’re almost all testing the driver.
> I had a chat with my coworkers and we agreed it's reasonable to
> replace them with lit tests (as they're just running commands).
> This would allow us to get rid of an external dependency, which
> happened to be cause of trouble in the past.
> 
> Are there any objections?
> 
> Thanks,
> 

I'm not a fan of pexpect, and if these tests can be converted to lit, 
then I'm all for it. But I do have a question.

There is a class of tests that cannot be written in the current lit 
framework, but they can with pexpect. A couple of weeks ago we had a 
patch fixing a bug where pressing up arrow while searching through the 
command history caused a crash. In the end a test for this was not 
included because it was hard for a reason unrelated to pexpect, but 
without pexpect (or something equivalent) writing a test for this would 
be impossible.

What's our story for testing interactive command-line functionalities? 
The way I see it, if we don't use pexpect, we'll either have to use some 
other tool which simulates a realistic terminal, or write our own. (We 
already have one attempt for this in 
unittests/Editline/EditlineTest.cpp, but this would need more work to be 
fully functional.)

pl


PS: Does anyone actually use the benchmark tests? Can we just delete them?