Hi Simon - 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