https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274671
Charlie Li <vish...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.freebsd.org/bu
| |gzilla/show_bug.cgi?id=2859
| |57
--- Comment #24 from Charlie Li <vish...@freebsd.org> ---
review D49680 is updated for 3.13.4.
(In reply to Konstantin Belousov from comment #22)
The build issues have been resolved, but packaging and possible circular
dependency issues persist, particularly when enabling the experimental
free-threaded mode. Free-threaded mode will most likely will be a child port
since it is effectively a separate distribution: while the same CPython
version, the ABIs are not compatible, and they have a few overlapping files
thus CONFLICTS_INSTALL. Some logic changes will also need to happen in
python.mk to accommodate this. While free-threaded mode and JIT are currently
officially experimental, they may not be experimental in future versions, so we
need to start accommodating them now.
The primary use case and mandate for the Python team has always been CPython
itself and the Python package ports. The use of virtual environments on CPython
and everything else is secondary. Please remember that many non-Python ports
have Python dependencies (examples: anything that builds using meson, ninja,
countless desktop programs implemented in other languages that incorporate
Python components). From a support perspective, actual nonsense is when we the
Python team get reports (formal or not) from those who manage their Python
packages outside of ports, like using pip in a virtual environment or not, that
we never had any primary semblance of QA over. (related: there is in fact a PEP
that expressly disallows pip et al from touching ${LOCALBASE} or ${PREFIX} that
we have not implemented yet, but is coming)
It is no longer possible to have a new CPython version without specifying it in
Mk/ as these ports themselves use the python.mk variables directly and
extensively. This was always the goal even prior to my involvement.
Anyway, this is more substantial than 3.12 (which itself was substantial). 3.12
still has issues with some of their ports which carry over to this version. For
this version, the new big dependency failure is cython: lang/cython 0.29 is
declared not supported on 3.13+ by upstream, but we still have many ports
depending on it that probably should change to lang/cython3 which is
compatible.
--
You are receiving this mail because:
You are the assignee for the bug.
