[Bug 274671] lang/python313: New port, 3.13.9 release

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274671

Charlie Li <vishwin@freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Open                        |Closed
         Resolution|---                         |FIXED

--- Comment #43 from Charlie Li <vishwin@freebsd.org> ---
The last issue that prevented this from landing dealt with ensuring that the
correct variant of this Python version built and packaged properly. Most
notably, the `python` or `python3` value of ${DEFAULT_VERSIONS} should not have
affected whether the resulting PKGNAME would be correct or staging and
packaging would behave itself.

Earlier during this cycle I committed support into the framework to allow for
Python versions that are not fully numeric, ie 3.13t. Previously the framework
assumed that versions are only numeric and thus numeric comparison operators
worked and made sense. Once it became clear that free-threaded mode required
its own FLAVOR and thus a separate port, adjustments to the version comparison
and flavour generation logic had to happen. So since then, theoretically the
py313 and py313t separate flavours have been possible.

The showstopper from having the lang/ ports committed at that same time stemmed
from this new support but in a different way. If lang/python313t is to be built
and DEFAULT_VERSIONS+=python=3.13t and DEFAULT_VERSIONS+=python3=3.13t, the
version comparison logic doesn't fire and thus ${PYTHON_VER} et al are correct
at 3.13t. The trouble lies when ${DEFAULT_VERSIONS} and the desired lang/python
port versions differ: the version comparison logic intended for *consumers*,
especially the flavoured ports, comes into play, which means the `t` is
immediately stripped so that the comparisons happen on fully-numeric values.
This path makes sense for consumers since they need to determine whether or not
a particular version or range is supported (3.13 and 3.13t for numerical
comparison and compatibility purposes are the same version). Unfortunately
there is not really a way to put the `t` back into ${PYTHON_VER} once this
finishes without there being a flavour defined, so building say lang/python313t
in this case would result in PYTHON_VER=3.13 instead of 3.13t. This ends up
messing with the resulting ${PKGNAME}, ${SUB_FILES} and the plist which
ultimately results in failed staging or packaging.

Mitigating around this was incredibly frustrating and is why it took so long.
Not proud of how long this took at all. Also not proud of how the explanation
had to come after everything worked (and thus committed) because of the amount
of moving parts in make(1) variables, which also made it nearly impossible to
accept any offers of help.

But now we have support for the free-threaded mode starting here at 3.13. 3.14
has developed this support further and hopefully the prematurely-committed port
will catch up soon. The generally incremental nature of CPython is why this
needed to be committed first; the port development cycles also follow this
pattern of starting from the previous version in a new copy.

-- 
You are receiving this mail because:
You are the assignee for the bug.