Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.maint.python > #17124

Re: Involving free-threaded Python in Debian (Was: Free-threaded python3.13t packaging in Debian?)

From ben0i0d <ben0i0d@foxmail.com>
Newsgroups linux.debian.maint.python
Subject Re: Involving free-threaded Python in Debian (Was: Free-threaded python3.13t packaging in Debian?)
Date 2025-11-04 09:50 +0100
Message-ID <LNkTL-amis-11@gated-at.bofh.it> (permalink)
References <Jw8qm-Ia8-5@gated-at.bofh.it> <Jw8qm-Ia8-3@gated-at.bofh.it> <LNkTL-amis-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

------------------------------------------------------------------------

Thanks for the invitation. I would like to briefly summarize the results 
of my previous communication with Stefano and the current status of my work.

Here are the repositories I have been working on. I have completed the 
build and testing of python3.14t and python3t. An experimental 
repository is also under my account:
https://salsa.debian.org/ben0i0d/python3t
https://salsa.debian.org/ben0i0d/python3t-defaults

In my previous work, I enabled |nogil| and the |t| flag to ensure that 
python3t is completely isolated from the existing Python line. That is, 
python3t/3.14t follows the “B” technical route. I isolated their 
|dist-packages|. (However, note that since I haven’t adapted pip 
packages yet, the current venv does not work properly, though manual pip 
installation works fine.)

When I communicated with Stefano via email, he agreed with the idea of 
using a suffix and nogil, but suggested two corrections:

 1.

    We cannot split out a separate python3t source package. The builds
    must produce two parallel interpreters from the existing CPython
    team packages (of course, they are isolated, including |/usr/lib|,
    i.e., the standard library is isolated).

 2.

    |dist-packages| should not be isolated. This way, we only need to
    focus on the porting, and if issues arise, venv can be used as a
    transition.

I agree with this view, and this is what I am currently doing—choosing 
option (a).

Regarding GIL vs. nogil, pure Python modules are usually not a problem, 
e.g., pip. The challenge lies in Python packages with C extensions.

 From my perspective, under option (a), the main issue only occurs when 
mixing GIL and nogil. Perhaps we should first introduce the nogil 
interpreter into Debian as a base, like Fedora, which could also bring 
nogil support to Ubuntu 26.04.

As for adapting modules for nogil, I don’t have a good solution yet. 
This problem will need to be discussed by the community, and I have not 
conducted tests or developed feasible approaches for mixed usage so far.

Ideally, I plan to complete option (a) within two weeks, i.e., finish 
the rules modifications and submit them.

At that time, I will carry out this part of the investigation.

Best regards,
*Xu Chen (ben0i0d)*

------------------------------------------------------------------------
在 2025/11/4 15:28, Chen Shengqi 写道:
> Xu Chen mentioned that he had some previous email with Stefanor, so I'm looping
> him into this thread.

Back to linux.debian.maint.python | Previous | Next | Find similar


Thread

Re: Involving free-threaded Python in Debian (Was: Free-threaded  python3.13t packaging in Debian?) ben0i0d <ben0i0d@foxmail.com> - 2025-11-04 09:50 +0100

csiph-web