GHA python refresh

[mdavidsaver]

See epics-base/epicscorelibs#46

Still work in progress.

[mdavidsaver]

The Linux 3.7 and 3.8 jobs are failing in ways which I am not able to reproduce.

The 3.7 job crashes during test execution. So far I have not been able to get a stack trace.

+ python -m nose2 -v p4p
/io/runit.sh: line 29:   114 Segmentation fault      (core dumped) python -m nose2 -v p4p

The 3.8 job fails during cythonize in the setup.py sdist step. Both numpy and Cython are installed. The same version of Cython succeeds with the 3.9 job.

Error compiling Cython file:
------------------------------------------------------------
...
    void opEvent(client.MonitorBuilder& builder, object handler)
    object monPop(const shared_ptr[client.Subscription]& mon) with gil

cimport numpy # must cimport after p4p.h is included

numpy.import_array()
     ^
------------------------------------------------------------
src/p4p/_p4p.pyx:65:5: cimported module has no attribute 'import_array'

[mdavidsaver]

stack trace from crash with py3.7.

  Thread 1 (Thread 0x7fb3d0dda700 (LWP 121)):
  #0  0x00007fb3ca5bf38f in pvxs::Member::~Member() () from /opt/python/cp37-cp37m/lib/python3.7/site-packages/p4p/_p4p.cpython-37m-x86_64-linux-gnu.so
  #1  0x00007fb3ca5bf41c in std::_Sp_counted_ptr_inplace<pvxs::Member, std::allocator<pvxs::Member>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() () from /opt/python/cp37-cp37m/lib/python3.7/site-packages/p4p/_p4p.cpython-37m-x86_64-linux-gnu.so
  #2  0x00007fb3ca5b99f7 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() () from /opt/python/cp37-cp37m/lib/python3.7/site-packages/p4p/_p4p.cpython-37m-x86_64-linux-gnu.so
  #3  0x00007fb3ca2fa7b3 in pvxs::TypeDef::TypeDef(pvxs::Value const&) () from /opt/python/cp37-cp37m/lib/python3.7/site-packages/p4p/../pvxslibs/lib/libpvxs.so.1.4
  #4  0x00007fb3ca5be0a3 in p4p::appendMembers () from /opt/python/cp37-cp37m/lib/python3.7/site-packages/p4p/_p4p.cpython-37m-x86_64-linux-gnu.so
  #5  0x00007fb3ca5bf08e in p4p::appendPrototype(pvxs::TypeDef&, _object*) () from /opt/python/cp37-cp37m/lib/python3.7/site-packages/p4p/_p4p.cpython-37m-x86_64-linux-gnu.so
  #6  0x00007fb3ca5aba85 in __pyx_pw_3p4p_4_p4p_5_Type_1__init__(_object*, _object*, _object*) () from /opt/python/cp37-cp37m/lib/python3.7/site-packages/p4p/_p4p.cpython-37m-x86_64-linux-gnu.so
  #7  0x000000000046fdd1 in ?? ()
  #8  0x0000000000436184 in _PyObject_FastCallKeywords ()
...

[mdavidsaver]

I think (epics-base/epicscorelibs#46 (comment)) the 3.7 and 3.8 issues will go away as updated dependency builds become available.

[mdavidsaver]

I think I have the P4P CI jobs straightened out now.

I gave up trying to figure out the crash with py3.7.

The Cython build dependency gets complex due to issues manifesting with py <= 3.8 which I'm not inclined to track down.

• All need Cython>0.29.32 for the noexcept keyword.
• py2.7 needs Cython < 3.0 to avoid error related to use of unbound function as bound (some monkey patching).
• py 3.8 needs Cython < 3.1 to avoid erroneous an error related to magic numpy.import_array() handling. I suspect this is a regression in Cython 3.2, but my patience has expired before I isolated it. Seems to be only on Linux, and may be numpy version dependent.

This is expressed in pyproject.toml as:

    "Cython>0.29.32, <3.0.0a1 ; python_version<'3.0'",
    "Cython>0.29.32, <3.1.0a1 ; python_version>='3.0' and python_version<'3.9'",
    "Cython>0.29.32 ; python_version>='3.9'",

(I expect there is a simpler way, but ... patience)