Re: Python BoF at DebConf2021
Hi debian-python (2021.08.26_07:14:20_+0000)
> I've taken it over, and started an Agenda:
> https://pad.dc21.debconf.org/p/20-python-team-bof
Notes from the BoF:
The video should be published in a couple of hours, to:
https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21/debconf21-97-python-team-bof.webm
Attendees:
Diane Trout and her cat
Elana Hashman
Emmanuel Arias
Jonathan Carter
Kyle Robbertze
Nicolas Dandrimont
Romain Porte
Stefano Rivera
Thomas Goirand
State of Python in Debian
=========================
Python 3.9 is currently the default, with 3.10 available in
experimental.
We plan to make 3.10 supported in unstable in October and then make it
default once RC issues are resolved.
We have been trying to mend the rift between Debian and upstream. Hard
to tell if things are any better. Some people upstream still recommend
avoiding Debian/Ubuntu Python. See "Other upstream issues" below.
Adding python3-full for bullseye was part of this.
We aren't ready for all PEP517-packaged modules. See below.
Debian Python Team Status
=========================
Volunteers always needed for team-wide maintenance, removals, etc.
Should we push towards git sources, as in:
https://lists.debian.org/debian-python/2021/06/msg00026.html
Consensus was yes, even if watch files continue to point to PyPI.
* ACTION: (olasd to propose) document policy change
-dbg module package removal
===========================
pydebug doesn't involve an ABI change any more, so all C extensions are
compatible with the -dbg interpreter, out of the box. We can retire our
-dbg packages, and migrate to automatic -dbgsym packages.
* ACTION: need tracker/list to be set up for package removal (no volunteers)
* ACTION: (olasd to ask pollo to) add a lintian warning for python-foo-dbg packages
python2.7 removal
=================
python2.7 is 99% removed, we're basically there.
We plan to remove python-is-python2 from bookworm.
pypy and pypy3 still build-depend on python2.7.
The rpython toolchain is being slowly ported to python 3, but the
upstream is in no hurry, as they maintain a Python 2.7 interpreter (but
provide no real security support for its standard library).
pypy can be migrated to be manually bootstrapped, or automatically
bootstrapped from cpython2.7 sources copied into the pypy source
package.
Is bookworm shipping with (CPython) 2.7?
We probably don't want to.
We may ship with a pypy 2.7, primarily for building pypy3.
Shall we keep virtualenv support for 2.7?
=========================================
This will require a separate pip stack for virtualenv.
Stefano is tempted to, for pypy (2.7)
Consensus is NO, we don't need to spend time on this.
pip in Debian
=============
Can't upgrade to the latest pip without dropping 2.7 support. Consensus
was to do this ASAP.
PEP 668 has been filed about making the ownership of packages between
apt and pip clearer:
https://discuss.python.org/t/graceful-cooperation-between-external-and-python-package-managers-pep-668/10302
pip has struggled to get sufficient maintenance over the years, more
maintainers would be appreciated.
A big part of its complexity is the de-vendoring of its dependencies.
Shall we vendor pip dependencies?
=================================
pip has a special place as the one and only tool you expect to have in
a virtualenv, so it vendors libraries that it depends on.
https://github.com/pypa/pip/tree/main/src/pip/_vendor
The de-vendoring mechanism was made in cooperation with upstream, but
they don't like it, and don't support our use of it.
It doesn't really provide the "single security update" benefit as
rebuilding the wheels needs a sourceful upload of pip
* ACTION: stefanor to open the conversation with the security team on what
they think about us re-vendoring the deps of pip (in terms of impact
on them).
PEP517 in Debian
================
The python world is moving to PEP517+518. They define how to build
python packages with tools like setuptools, however they only define the
process to build wheels, not to install packages into the system.
We need to create build tools that can drive pep517 + pypa/install and
then install the wheel, unpacked.
dh-python already supports flit, directly, not using the pep517
mechanisms.
Emmanuel is working on poetry support, and will look at more general
tooling after that.
Other upstream issues to be aware of:
https://bugs.python.org/issue43976 - Add vendor information
https://bugs.python.org/issue44982 - Allow Python distributors to add
custom site install schemes
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Reply to: