Bug#1008954: uwsgi-plugin-python3: uWSGI uses Python 3.10 which is not yet the default
Adrien CLERC
Version: 2.0.20-4+b1
Severity: important
Dear Maintainer,
uwsgi was rebuilt with python 3.10 as default, but it is not yet the Debian
default version. I have some applications that use a virtualenv with python
3.9, and uwsgi fails to load those applications since the python version is not
the same.
Is it possible to wait for python 3.10 to be the default before hitting
testing?
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.16.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages uwsgi-plugin-python3 depends on:
ii libc6 2.33-7
ii libpython3.10 3.10.4-2
pn uwsgi-core <none>
uwsgi-plugin-python3 recommends no packages.
Versions of packages uwsgi-plugin-python3 suggests:
pn python3-uwsgidecorators <none>
Jonas Smedegaard
Quoting Adrien CLERC (2022-04-04 22:52:59)
> Debian default version. I have some applications that use a virtualenv
> with python 3.9, and uwsgi fails to load those applications since the
> python version is not the same.
> Is it possible to wait for python 3.10 to be the default before
> hitting testing?
I did a simple rebuild, so if that caused the package to treat Python
3.10 as the default then that is because it is the default (at the
Debian unstable environment where it was built).
If you mean to say that Python 3.10 is not yet the default in testing,
then that seems like a chicken-and-egg scenario: For Python 3.10 to
become the default in Debian testing, packages rebuild while Python 3.10
was the default need to migrate to testing.
If your system is not yet ready for Python 3.10, then I suggest you hold
back packages as appropriate.
If I somehow missed your point, then please try again, and sorry for not
understanding you properly.
Kind regards,
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
Adrien CLERC
Sorry, I am not sure I understand you. I did a simple rebuild, so if that caused the package to treat Python 3.10 as the default then that is because it is the default (at the Debian unstable environment where it was built). If you mean to say that Python 3.10 is not yet the default in testing, then that seems like a chicken-and-egg scenario: For Python 3.10 to become the default in Debian testing, packages rebuild while Python 3.10 was the default need to migrate to testing. If your system is not yet ready for Python 3.10, then I suggest you hold back packages as appropriate.
Thanks for your explanation. Indeed, the surprise lies in the socket activation of uwsgi. The "apt upgrade" went fine, but since my application uses a virtualenv that was created with Python 3.9, uwsgi can't find any required dependencies, they were all in the python3.9 subdirectory, and uwsgi python plugin looked for python3.10. At first activation of the application, it failed, and the reason was hard to find.
The main issue for me was that I have to install python3.10
manually to upgrade the virtualenv, since it was not installed
automatically by any package, especially the python3 package. I
was expecting somehow that the migration was synchronized, but as
you mentioned, it might be not realistic.
If nothing can be done about this, please close this!
Have a good day,
Adrien