Miscellaneous corrections

[pheest]

This PR makes some largely cosmetic corrections that I noticed.

In disect.py (for Python2 use) InstanceType is imported.
This will fail with Python3 and the exception is caught.
The value of InstanceType is checked for None later.
However, in these circumstances, the value is not None but is undefined.
This causes the application to fail.
It is used only by the example programs.
It gives a bad impression to novice users of the module.
A better solution approach would be to remove it altogether. That's for another day.

In requirements-deb10.txt, nose(1) is specified as a requirement, but commented out.
The line is not required.

In ci-scipts-build.yml, I have added workflow_dispatch as a manual trigger for build.
I sometimes find it convenient to do so.
I'm aware that when base 3.14 is used, it will compile but tests cannot be run.
It is helpful to make this explicitly clear with a comment in the test matrix.

I dbfield.c, include of Python.h is not required.
aval can be declared as a PyArrayObject (rather than a PyObject).
This avoids the need for subsequent casting.

In setup.c, PyEval_InintThreads is called.
In later versions of NumPy it does nothing except to issue an irritated deprecation warning

[tynanford]

Hi @pheest , all the changes look good except the aval update breaks the compile on gcc 16 which got more picky:

../dbfield.c:161:15: error: assignment to ‘PyArrayObject *’ {aka ‘struct tagPyArrayObject_fields *’} from incompatible pointer type ‘PyObject *’ {aka ‘struct _object *’} [-Wincompatible-pointer-types]
  161 |     if(!(aval = PyArray_FromAny(arr, desc, 1, 2, NPY_ARRAY_C_CONTIGUOUS | NPY_ARRAY_ALIGNED | NPY_ARRAY_WRITEABLE, arr)))
      |               ^

Casting that to PyArrayObject at creation should fix that

diff --git a/devsupApp/src/dbfield.c b/devsupApp/src/dbfield.c
index abca9f0..87f6d5a 100644
--- a/devsupApp/src/dbfield.c
+++ b/devsupApp/src/dbfield.c
@@ -158,7 +158,7 @@ static int assign_array(DBADDR *paddr, PyObject *arr)
     }
 
     Py_XINCREF(desc);
-    if(!(aval = PyArray_FromAny(arr, desc, 1, 2, NPY_ARRAY_C_CONTIGUOUS | NPY_ARRAY_ALIGNED | NPY_ARRAY_WRITEABLE, arr)))
+    if(!(aval = (PyArrayObject *)PyArray_FromAny(arr, desc, 1, 2, NPY_ARRAY_C_CONTIGUOUS | NPY_ARRAY_ALIGNED | NPY_ARRAY_WRITEABLE, arr)))
         return 1;
 
     if(elemsize!=PyArray_ITEMSIZE(aval)) {

[pheest]

OK, I wondered about the silent upcast.
I have added the change.

I also added some documentary comments regarding use of static builds which cannot work for the module.
(This being an issue that I fell over early in the project (@mdavidsaver had to explain it to me).

[tynanford]

Minor thing but I still get the deprecation warning with numpy 2.4.6 and python 3.14.6.

../setup.c: In function ‘pySetupReg’:
../setup.c:135:5: warning: ‘PyEval_InitThreads’ is deprecated [-Wdeprecated-declarations]
  135 |     PyEval_InitThreads();
      |     ^~~~~~~~~~~~~~~~~~
In file included from /usr/include/python3.14/Python.h:135,
                 from ../setup.c:8:
/usr/include/python3.14/ceval.h:114:37: note: declared here
  114 | Py_DEPRECATED(3.9) PyAPI_FUNC(void) PyEval_InitThreads(void);
      |                                     ^~~~~~~~~~~~~~~~~~
/usr/bin/ar -rc    libpyDevSup3.14.a    setup.o 

I think this should check if python is less than 3.7?

diff --git a/pyIocApp/setup.c b/pyIocApp/setup.c
index 0f87fe2..e9e36ca 100644
--- a/pyIocApp/setup.c
+++ b/pyIocApp/setup.c
@@ -130,8 +130,8 @@ static void cleanupPrep(initHookState state)
 static void pySetupReg(void)
 {
     Py_InitializeEx(0);
-#if NPY_TARGET_VERSION < NPY_1_9_API_VERSION
-    /* See https://docs.python.org/3/whatsnew/3.9.html */
+#if PY_VERSION_HEX < 0x03070000
+    /* See https://docs.python.org/3/c-api/threads.html#c.PyEval_InitThreads */
     PyEval_InitThreads();
 #endif

[pheest]

You are correct. I Googled the warning and hit on the NumPy page.
Whereas the logic condition has nothing to do with NumPy (other than the supported Python version).