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

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

Am Thu, 8 May 2025 15:22:53 +0200
schrieb Thomas Klausner <wiz%gatalith.at@localhost>:

> On Thu, May 08, 2025 at 03:21:35PM +0200, Thomas Klausner wrote:
> > On Thu, May 08, 2025 at 03:16:27PM +0200, Dr. Thomas Orgis wrote:  
> > > 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 think that's not uncommon, and the main reason we rename bin/foo to
> > bin/foo-3.12.
> > 
> > You can set PYTHON_SELF_CONFLICT for Python packages where there are
> > conflicts between py311-foo and py312-foo (etc.)  

In this case I'd argue that it doesn't make sense to build ALPS
multiple times for differing pythons. You'd need to teach dependent
packages (which is DIRAC, in my case) about funky renamed binaries
(programs and libraries, headers). I don't really see that happening.

But to the point, if I werer to package ALPS, would you prefer to have
it named science/py-alps (remembering a discussion about category names
some time ago … ) with all the python naming stuff and
PYTHON_SELF_CONFLICT or rather have it as non-versioned science/alps
with

PYTHON_VERSIONS_ACCEPTED=  ${PYTHON_VERSION_DEFAULT}

?

If DIRAC were to follow (probably not because of non-free license that
enforces citations?), would that then also need to be python-versioned
if depending on py-alps? At some point we install multiple versions of
something like libreoffice because it can embed a python interpreter?
Is everything affected by python going to be multiversioned?

> Just in case there was a misunderstanding about boost-python - we have
> py-boost, which is a versioned package, which allows parallel install
> for multiple versions of Python.

Yes. I got several incarnations of py-boost installed, none of which
was usable by the ALPS build because it only expects
libboost_python.so, not libboost_python$PYVER.so;-) But they (cmake,
boost) are trying with the cmake machinery installed by py-boost … just
needs some decades for scientifc software packages getting rid of their
boost detection code and port to the new standard thingie, among fixing
lots of other complaints cmake has with new policies and deprecations.

I must admit, though, that I begin to question my choice to build
several versions of python3 for our users in one pkgsrc tree. Maybe the
time has come at some point to reduce that number to 1 again … now since
python2 is just barely rocking on the deathbed.


Alrighty then,

Thomas

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