https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274671
Charlie Li <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed Resolution|--- |FIXED --- Comment #43 from Charlie Li <[email protected]> --- 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.
