python_variants branch report

[Joshua Root]

Hi Vincent,

On 13/8/2026 02:24, Vincent Habchi wrote:
> Folks,
> 
> The python_variants branch is more or less ready to be tested in view of its (possible) merging into main. Let me remind you exactly what is on this branch:

Thanks for your work on this.

> – A python 1.1 PortGroup file that handles the upcoming freethreading Python releases. These releases, starting with 3.15, have their ‘names’ end with a -t (ex.: 315t). The problem is that the corresponding ${python.version} in Python 1.0 PortGroup is not guaranteed to be numeric any more. Solution: python 1.1 PortGroup guarantees ${python.version} to be numeric (315 for python3.15t) so that the current numeric comparisons in the various py-* ports are safe (ex.: if {${python.version} >= 310} … The new variable ${python.suffix} contains the full version (ex.: python3.15t → 315t), which must be used for dependencies.

Please don't add a new version of the python portgroup or use a 
different python.version string for abi3t builds. That will just lead to 
unnecessary duplication of a lot of modules.

The two ABIs are not partially overlapping, but rather abi3t is a proper 
subset of abi3. AIUI the headers installed by freethreading python are 
not different and all extension modules that build for abi3t do so by 
setting a preprocessor macro (as well as first ensuring that they don't 
use any symbols that are not in abi3t).

Build backends that build extension modules usually have options to 
choose the ABI, and projects that support abi3t will normally be using 
them already. We should build such modules for either both abi3t and 
abi3 or just abi3t (since traditional GIL python can use abi3t modules).

> – A python_variants 1.0 PortGroup file. This port group file allows the choice of a default python version using a variant specified in ${prefix}/etc/macports/variants.conf (ex.: +python315t). Inside a portfile, the allowed variants are specified using a line beginning with python_variants, and the selected variant is available in ${python.variant}, while ${python.branch} contains the corresponding suffix for the binary (ex.: 3.15t). The port group adds a depends_lib to the corresponding python port automatically. It handles the case where the variant does not correspond to the port name (ex.: variant 315t corresponds to port python315-freetheading-devel) using a trick on the python.variants line. Specific code to be executed for python variant handling can also be specified in a bloc python.variant_code. Detailed documentation is available in the PortGroup file.

The interface sounds fine. Initial impression is that it's quite a lot 
of code for what it does. The comments are also very verbose. Please 
remove the "eval [subst { ..." construct, that's an antipattern.

> – A perl_variants 1.0 PortGroup file. Same principle as python_variants, but for perl dependent ports. In this case, there is no ${perl.branch} variable since the variants are spelled with the separating dot (ex.: perl.variants 5.34 5.36 5.38 5.40 5.42). These two new portgroups mimic what FreeBSD port(1) does using mk.conf customisation.

How does this differ from perl5.create_variants in the perl5 portgroup?

> - I have updated all p5-* ports to use recent perl versions up to 5.42.
Great! That will need to be merged to master separately though, and as 
multiple commits over time so it doesn't overload the buildbot.

- Josh