python3-ipython: update to 8.14.0.

[tornaria]

• switch to pep517 build style: needs using a venv
• update depends and checkdepends
• break unnecessary checkdepends cycle with ipython_ipykernel

Testing the changes

• I tested the changes in this PR: briefly

I will run sagemath testsuite with this update and report back.

@ahesford here's one package where testing with PYTHONPATH breaks and testing in a venv works. I wrote a custom do_check() function but you'll see it's quite generic and could be moved to build-style/python3-pep517.sh.

Maybe you can figure out a different way to make the generic testing with PYTHONPATH to work.

[tornaria]

There was a test failure on x86_64-musl:

FAILED IPython/utils/tests/test_process.py::SubProcessTestCase::test_system_interrupt

But in my local test this passed.

[tornaria]

I rerun CI without changes and got the same failure. Locally I can reproduce if I change the sleep time from 0.5 to 0.0.

I added a reasonably looking patch that I submitted upstream at ipython/ipython#12164. Now all tests pass (even with sleep time 0.0).

I also run the sage testsuite with this update without any issue so this is ready to merge.

I would appreciate any comments on what to do about do_check().

[ahesford]

The problem isn't that this works in a venv, it's how you're calling pytest. The default do_build runs pytest3 but you are running python3 -m pytest, which means you add . to the Python path by default. If you were to run

ln -Tsf /usr/bin/pytest3 "${testdir}/bin/pytest3"
"${testdir}/bin/pytest3"

instead of python3 -m pytest, the tests would again fail with an inability to find IPython.

This suggests that pytest is not actually testing against the contents of the wheel, but is instead testing the contents of the source tree. (Although, in the single test test_ipython_embed, it expects to find an ipython entrypoint and fails.) In fact, it is sufficient to do

do_check() {
    python3 -m pytest -k 'not(test_ipython_embed)'
}

for a successful test run.

[tornaria]

The problem isn't that this works in a venv, it's how you're calling pytest. The default do_build runs pytest3 but you are running python3 -m pytest, which means you add . to the Python path by default.

I see, it's really misleading that the python path changes depending on this.

If you were to run

ln -Tsf /usr/bin/pytest3 "${testdir}/bin/pytest3"
"${testdir}/bin/pytest3"

instead of python3 -m pytest, the tests would again fail with an inability to find IPython.

I don' t think that will run pytest in the venv, since the shebang for /usr/bin/pytest3 is /usr/bin/python3. It does what you claim if I do something like

"${testdir}/bin/python3" /usr/bin/pytest3

so TIL that python3 -m pytest is not the same as python3 /usr/bin/pytest.

This suggests that pytest is not actually testing against the contents of the wheel, but is instead testing the contents of the source tree.

Sure and since all the test files are actually installed in the wheel, we get a conflict between the files pytest is trying to load (from .) and the modules that are installed in $testdir.

So an easy way to make . into the python path would be

make_check_pre='env PYTHONPATH=.'

With this in place and the standard do_check(), all tests pass (even test_ipython_embed). What do you think?

[ahesford]

I think that's the best option, because it requires a single line without overriding the default functions.