Re: bin/pip3.12 or bin/pip-3.12

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

Am Wed, 7 May 2025 09:55:40 +0100
schrieb David Brownlee <abs%absd.org@localhost>:

> A possible variant - have dash for everything, but for those four
> exceptions _also_ have a link from the version without the dash?

I hesitate with such. My feeling is that we cause more confusion by
creating pythnon-3.12 in additon to the python3.12 that every one knows
and expects (if not plain python3 or python, even). Should pkgsrc be
the first to push a consistent scheme and create portability problems
with names that only exist for pkgsrc installs?

While on the topic of pkgsrc installs, I tried to make an installation
of ALPS

https://alps.comp-phys.org/documentation/install/source/
https://github.com/ALPSim/ALPS

outside pkgsrc for now, but using it as infrastructure.

(They do not mention release tarballs in their docs, but there exist
some on GitHub. Strange, somewhat. They build binaries for pypi only,
but there is discussion on supporting more packaging … what about just
doing proper source releases and letting packagers package it?)

After hacking around in its custom FindBoost cmake scripts, I managed
it to _try_ to use Boost as installed by pkgsrc, but then it failed to
link -lboost and -lboost_python. The former doesn't exist at all in the
pkgsrc install (a build-time choice to install the libboost_*.so or one
big libboost.so, I presume), while the letter does, sort of:

$ ls .prefix/lib/libboost_python31*|cat
.prefix/lib/libboost_python310.a
.prefix/lib/libboost_python310.so
.prefix/lib/libboost_python310.so.1.87.0
.prefix/lib/libboost_python311.a
.prefix/lib/libboost_python311.so
.prefix/lib/libboost_python311.so.1.87.0
.prefix/lib/libboost_python312.a
.prefix/lib/libboost_python312.so
.prefix/lib/libboost_python312.so.1.87.0

Observe another instance of version suffix without hyphens and dots. Is
this something upstream does? I guess so … there's elaborate
infrastructure for cmake

$ ls -l  .prefix/lib/cmake/boost_python-1.87.0/|cat
total 32
-rw-r--r-- 1 sw sw  304 May  5 03:11 boost_python-config-version.cmake
-rw-r--r-- 1 sw sw 3803 May  5 03:11 boost_python-config.cmake
-rw-r--r-- 1 sw sw 3280 May  5 03:22 libboost_python-variant-shared-py3.10.cmake
-rw-r--r-- 1 sw sw 3280 May  5 03:33 libboost_python-variant-shared-py3.11.cmake
-rw-r--r-- 1 sw sw 3280 May  5 03:45 libboost_python-variant-shared-py3.12.cmake
-rw-r--r-- 1 sw sw 3334 May  5 03:22 libboost_python-variant-static-py3.10.cmake
-rw-r--r-- 1 sw sw 3334 May  5 03:33 libboost_python-variant-static-py3.11.cmake
-rw-r--r-- 1 sw sw 3334 May  5 03:45 libboost_python-variant-static-py3.12.cmake

… that doesn't help ALPS a bit, as it's using deprecated and also
custom code on top to do its Boost stuff. Boost and Python. CMake. All
these together left deep scars in my soul already, just getting things
to build with them. Especially for science software that accumulated
lots of custom cmake hackery.

So, I'm letting ALPS download and build its own copy of Boost for now.
Someone might fix its cmake stuff and make it work with pkgsrc and
Python versions. But then: This software provides dozens on unversioned
binaries and libraries, along with lots of other shared files.

Among the installed files are versioned python modules

lib/python3.12/site-packages/pyalps
[…]

but also:

lib/python/alps/config.py

And the main tools are linking to the specific python version

$ readelf -d  lib/libalps.so|grep NEEDED|grep python
 0x0000000000000001 (NEEDED)             Shared library: [libboost_python.so]
 0x0000000000000001 (NEEDED)             Shared library: [libpython3.12.so.1.0]

So not just bindings that could be separated.

How would be handle such sofware, if it were to be packaged in pkgsrc?
It needs some version of python, with boost-python, which supports
differing concurrent pythons, but it itself can only live once in the
system. I guess that means

PYTHON_VERSIONS_ACCEPTED=  ${PYTHON_VERSION_DEFAULT}

in Makefile? There's not much packages that do that right now. Only a
handful. But one interesting find in graphics/vigra/Makefile:

# Best we can do without pulling in a python dependency.
# Update when PYTHON_VERSION_DEFAULT changes!
SUBST_SED.python+=      -e 's,/usr/bin/env.*python,${PREFIX}/bin/python2.7,'
SUBST_MESSAGE.python=   Fixing path to python.

I have the grave suspicion that this has _not_ been updated when
changed PYTHON_VERSION_DEFAULT came along …

But anyway, my main point was to mention that libpython3.12.so is also
a thing regarding a consistent versioned naming scheme.


Alrighty then,

Thomas

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