python version confusion with cython (Re: math/py-scipy)

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

OK, I am trying to test this and stumble over something along

https://github.com/scipy/scipy/issues/17808

I don't have cython or cython3 in my pkgsrc prefix. I do have
$PREFIX/bin/cython-3.10 (and cythonize-3.10). We have cython handled
along with all usual python cruft with multiversion support.

A comment on that scipy issue argues that even debian naming the py3
variant cython3 is a grave mistake, as it's a command-line tool and not
a python library. But of course it comes with python libraries and I
really have no clue how agnostic this tool is regarding actual python
version.

Let's suppose it was agnostic: Is the pkgsrc way of installing multiple
instances of the tool sensible? One one install, I got cython-3.8 and
cython-3.9. It could be more.

For our HPC installs, I do link python3 to the primary py3 version
after pkgsrc installs (same with pip3 and some others), but I don't centrally
put a plain python link there. I do offer an environment module for
users to say 'I want python 3 as default' which provides wrappers that
call python3 (whereever it resides in their base environment) on
invoking `python`.

I think it's fine for pkgsrc not to decide wich python3 is 'the'
python3, as well as it doesn't decide if python3 should also be simply
called python.

But is this correct for something that claims to have the python
version as implementation detail? Should we install a cython →
cython-3.10 symlink or rather not multiversion cython at all, just have
it use default python? Would that even work?


Alrighty then,

Thomas

PS: Still not sure how anything else finds and uses cython … maybe
other builds hardcode cython-3.Y to match the python used otherwise?
Python versioning really has earned a place in the history books as an
example on how to cause pain and confusion.

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg