Thank you for your reply...

On Thu, 12 Jan 2023 16:43:20 +1030, Simon Lees wrote:

>On 1/10/23 09:08, Glen Barney wrote:

>> I have a number of 15.4 servers, which have been upgraded from previous

>> recent Leap versions. These servers have the legacy Python 2.7, the

>> current Python 3.6, and the newer Python 3.9 package groups all

>> installed, side by side, and all working properly.

>> However.... attempts to install Python 3.10 fail, with what appear to be

>> dependency conflicts against Python 3.9.

>It seems more like there is a conflict in something like python-tools or

>python-setuptools, maybe you can remove the 3.9 version manually and

>that will make the resolver happier. On my tumbleweed system I certainly

>still have both installed but that is setup differently.

Alas, I've tried various combinations without luck.  And this is an operational

development server on Leap 15.4, so I can't switch to TW in this case.

To try to narrow this down further, I just created a freshly-loaded default

install of 15.4 on a brand new (virtual) machine.  The default install

loaded Python 3.6, as expected.  I then tried this:

# zypper in python39 python310

And got this:

Loading repository data...

Reading installed packages...

Resolving package dependencies...

Problem: the to be installed python310-3.10.8-150400.4.15.1.x86_64 obsoletes 'python39' provided by the to be installed python39-3.9.15-150300.4.21.1.x86_64

 Solution 1: do not install python39-3.9.15-150300.4.21.1.x86_64

 Solution 2: do not install python310-3.10.8-150400.4.15.1.x86_64

Choose from above solutions by number or cancel [1/2/c/d/?] (c):

This doesn't make sense to me, because if I download the RPMs and list them out,

everything seems co-compatible:

# rpm -q -l python39-3.9.15-150300.4.21.1.x86_64.rpm

/usr/lib64/python3.9

/usr/lib64/python3.9/lib-dynload

/usr/lib64/python3.9/lib-dynload/_sqlite3.cpython-39-x86_64-linux-gnu.so

/usr/lib64/python3.9/lib-dynload/nis.cpython-39-x86_64-linux-gnu.so

/usr/lib64/python3.9/lib-dynload/readline.cpython-39-x86_64-linux-gnu.so

/usr/lib64/python3.9/sqlite3

/usr/lib64/python3.9/sqlite3/__init__.py

/usr/lib64/python3.9/sqlite3/__pycache__

/usr/lib64/python3.9/sqlite3/__pycache__/__init__.cpython-39.opt-1.pyc

/usr/lib64/python3.9/sqlite3/__pycache__/__init__.cpython-39.opt-2.pyc

/usr/lib64/python3.9/sqlite3/__pycache__/__init__.cpython-39.pyc

/usr/lib64/python3.9/sqlite3/__pycache__/dbapi2.cpython-39.opt-1.pyc

/usr/lib64/python3.9/sqlite3/__pycache__/dbapi2.cpython-39.opt-2.pyc

/usr/lib64/python3.9/sqlite3/__pycache__/dbapi2.cpython-39.pyc

/usr/lib64/python3.9/sqlite3/__pycache__/dump.cpython-39.opt-1.pyc

/usr/lib64/python3.9/sqlite3/__pycache__/dump.cpython-39.opt-2.pyc

/usr/lib64/python3.9/sqlite3/__pycache__/dump.cpython-39.pyc

/usr/lib64/python3.9/sqlite3/dbapi2.py

/usr/lib64/python3.9/sqlite3/dump.py

# rpm -q -l python310-3.10.8-150400.4.15.1.x86_64.rpm

/usr/lib64/python3.10

/usr/lib64/python3.10/lib-dynload

/usr/lib64/python3.10/lib-dynload/_sqlite3.cpython-310-x86_64-linux-gnu.so

/usr/lib64/python3.10/lib-dynload/nis.cpython-310-x86_64-linux-gnu.so

/usr/lib64/python3.10/lib-dynload/readline.cpython-310-x86_64-linux-gnu.so

/usr/lib64/python3.10/sqlite3

/usr/lib64/python3.10/sqlite3/__init__.py

/usr/lib64/python3.10/sqlite3/__pycache__

/usr/lib64/python3.10/sqlite3/__pycache__/__init__.cpython-310.opt-1.pyc

/usr/lib64/python3.10/sqlite3/__pycache__/__init__.cpython-310.opt-2.pyc

/usr/lib64/python3.10/sqlite3/__pycache__/__init__.cpython-310.pyc

/usr/lib64/python3.10/sqlite3/__pycache__/dbapi2.cpython-310.opt-1.pyc

/usr/lib64/python3.10/sqlite3/__pycache__/dbapi2.cpython-310.opt-2.pyc

/usr/lib64/python3.10/sqlite3/__pycache__/dbapi2.cpython-310.pyc

/usr/lib64/python3.10/sqlite3/__pycache__/dump.cpython-310.opt-1.pyc

/usr/lib64/python3.10/sqlite3/__pycache__/dump.cpython-310.opt-2.pyc

/usr/lib64/python3.10/sqlite3/__pycache__/dump.cpython-310.pyc

/usr/lib64/python3.10/sqlite3/dbapi2.py

/usr/lib64/python3.10/sqlite3/dump.py

Simiarly for pip...

# rpm -q -l python39-pip-20.2.4-7.8.1.noarch.rpm | grep -v -e 3.9 -e 39

/etc/alternatives/pip

# rpm -q -l python310-pip-20.2.4-150400.1.19.noarch.rpm | grep -v 10

/etc/alternatives/pip

/etc/alternatives/pip3

/usr/bin/pip

/usr/bin/pip3

And setuptools...

# rpm -q -l python39-setuptools-44.1.1-7.3.1.noarch.rpm | grep -v -e 3.9 -e 39

/etc/alternatives/easy_install

/usr/bin/easy_install

/usr/bin/easy_install-

# rpm -q -l python310-setuptools-57.4.0-150400.2.14.noarch.rpm | grep -v 10

(no output at all, everything in a 3.10 subdirectory)

And python-tools...

# rpm -q -l python39-tools-3.9.15-150300.4.21.1.x86_64.rpm | grep -v -e 3.9 -e 39

(no output)

# rpm -q -l python310-tools-3.10.8-150400.4.15.1.x86_64.rpm | grep -v 10

(no output)

My goal here is to have Python 3.10 installed alongside 3.9, so that

developer users can migrate their code having both platforms available.

It seems like the packages should co-exist nicely - Python seems built to

allow versions to co-exist nicely - and yet even the basic packages here

refuse to be installed together.

This is what I'm trying to understand and work around.

Thank you for any insight you can provide!

Glen