Created attachment 245824 [details] python-3.13.0a1 - New ports, python-3.13.0a1 test results: == Tests result: FAILURE then FAILURE == 10 slowest tests: - test_tools: 6 min 26 sec - test_smtpnet: 5 min - test_socket: 4 min 15 sec - test_ssl: 1 min 15 sec - test_imaplib: 51.2 sec - test.test_concurrent_futures.test_wait: 47.9 sec - test_signal: 47.0 sec - test_subprocess: 45.1 sec - test.test_multiprocessing_spawn.test_processes: 43.7 sec - test.test_multiprocessing_spawn.test_threads: 42.1 sec 27 tests skipped: test.test_asyncio.test_windows_events test.test_asyncio.test_windows_utils test.test_gdb.test_backtrace test.test_gdb.test_cfunction test.test_gdb.test_cfunction_full test.test_gdb.test_misc test.test_gdb.test_pretty_print test_dbm_gnu test_devpoll test_epoll test_idle test_ioctl test_launcher test_msvcrt test_perf_profiler test_perfmaps test_sqlite3 test_startfile test_tcl test_tkinter test_ttk test_ttk_textonly test_turtle test_winconsoleio test_winreg test_winsound test_wmi 1 test skipped (resource denied): test_zipfile64 2 re-run tests: test.test_concurrent_futures.test_shutdown test_dtrace 1 test failed: test_dtrace 440 tests OK. Total duration: 8 min 19 sec Total tests: run=39,403 failures=17 skipped=1,334 Total test files: run=470/469 failed=1 skipped=27 resource_denied=1 rerun=2 Result: FAILURE then FAILURE *** Error code 2
Created attachment 247766 [details] Update to alpha3 Update to alpha3
Created attachment 248522 [details] python-3.13.0a4 Python-3.13.0 alpha4
Created attachment 249232 [details] Update to 3.13.0 alpha5 Update to 3.13.0 alpha5
Created attachment 249928 [details] Update to 3.13.0a6 Update to alpha6
Created attachment 250546 [details] Update to 3.13.0beta1 Update to python-3.13.0beta1
Created attachment 251261 [details] Update to 3.13.0 beta2 Update to 3.13.0 beta2
Created attachment 252441 [details] Python-3.13.0rc1 Python-3.13.0rc1
Created attachment 253973 [details] Update to 3.13.0rc3 Update to 3.13.0rc3
Created attachment 254094 [details] Update to 3.13.0 release Update to 3.13.0 release
Created attachment 255638 [details] Update to 3.13.1 Update to 3.13.1
When will this be added to the FreeBSD port tree?
Created attachment 257308 [details] Update to 3.13.2 Update to 3.13.2
What exactly prevents the committing of lang/python3.13 as a new port. I do see Wen's attachments but not an initial commit for creating the port. I do need to understand the criteria/policy if any for porting new Python releases. We had python 3.10.0.beta4, 3.10.0rc1, 3.10.0rc2 as ports but do fail to provide actual Python releases for 3.12 and 3.12. What's going on here please? What is the point of failure? I do NOT criticize Wen here, as he is doing a great job by providing port-upgrades for Python in typically less than 5 days. And he is the one providing upgrade attachments. But there is an issue for getting the first (3.x.0 versions) releases in a reasonable timely manner as a port. And yes, upgrading Python default versions looked also more like <fill in a appropriate word yourself> than anything else. But this is another story and still needs to be improved.
Please increase Importance: --- Affects Only Me ---> Affects some people
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=de7c5ca4a2d40df82a8ca46b37c8b859a412b89c commit de7c5ca4a2d40df82a8ca46b37c8b859a412b89c Author: Charlie Li <vishwin@FreeBSD.org> AuthorDate: 2025-04-05 20:12:38 +0000 Commit: Charlie Li <vishwin@FreeBSD.org> CommitDate: 2025-04-05 20:12:38 +0000 devel/py-wheel044: "temporarily" add The sole purpose of this port is to build setuptools < 70.1.0 under USE_PYTHON=pep517, as a stopgap to allow newer Python distributions/interpreters to land while the setuptools update continues to be worked on. This port will be removed once setuptools is updated. Nothing else is to declare this as a dependency; continue to use devel/py-wheel elsewhere. As of setuptools 70.1.0, bdist_wheel (what setuptools executes as part of ${PEP517_BUILD_CMD} to build the wheel) has moved from wheel to setuptools [0], so once setuptools is updated past said version, consumers should not continue declaring devel/py-wheel in BUILD_DEPENDS unless the package needs functionality beyond what moved into setuptools. [0] https://setuptools.pypa.io/en/latest/history.html#v70-1-0 PR: 271673, 274671 devel/Makefile | 1 + devel/py-wheel044/Makefile (new) | 26 +++++++++ devel/py-wheel044/distinfo (new) | 3 ++ .../files/patch-src_wheel___bdist__wheel.py (new) | 62 ++++++++++++++++++++++ devel/py-wheel044/pkg-descr (new) | 13 +++++ 5 files changed, 105 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=8b5ae17d2f43388fade30e266615a9e34bf06abd commit 8b5ae17d2f43388fade30e266615a9e34bf06abd Author: Charlie Li <vishwin@FreeBSD.org> AuthorDate: 2025-04-05 20:45:55 +0000 Commit: Charlie Li <vishwin@FreeBSD.org> CommitDate: 2025-04-05 20:45:55 +0000 devel/py-setuptools: convert to USE_PYTHON=pep517 The previous method of building/bootstrapping setuptools via the built-in distutils module no longer works in Python 3.12+ as it has been removed [0]. Since USE_PYTHON=pep517 has its own bootstrapping process, use this method to build setuptools. This allows newer Python distributions/interpreters to land in the tree, for the purpose of having buildable packages. While here, remove a slew of dead code and adjust WWW [0] https://peps.python.org/pep-0632/ PR: 271673, 274671 devel/py-setuptools/Makefile | 39 ++++++---------------- .../files/easy-install.pth.dist (gone) | 2 -- .../patch-setuptools_package__index.py (gone) | 11 ------ devel/py-setuptools/files/pkg-message.in (gone) | 8 ----- 4 files changed, 10 insertions(+), 50 deletions(-)
Took wen@'s attachment, cleaned it up a bit, posted at review D49680. Feel free to test for any showstoppers. Amongst other new features [0] are experimental free-threaded/Global Interpreter Lock-disabled support and JIT compiler. They are to be exposed but not enabled by default in the port. [0] https://docs.python.org/3/whatsnew/3.13.html
Sorry, but why did 3.13 still not committed to the tree? What we are waiting for? A release for 3.33?
Created attachment 260991 [details] Update to python-3.13.4 Update to 3.13.4
(In reply to wen from comment #19) Could you please just commit this?
(In reply to Konstantin Belousov from comment #20) No. In certain cases this actually doesn't even build. Also not to mention another large swath of packages are ignored because of one package that upstream declared not compatible with this version.
(In reply to Charlie Li from comment #21) Please be much more specific. What are configurations where 'this' (I assume python 3.13 itself) does not build? And please stop repeating the nonsense about py-* packages. The python itself + virtual envs is the use case, and you block this usage, factually blocking FreeBSD usage in important situations Lots of ports break with 3.12, but the earth did not stopped. It was said many times, it is fine to not have all python versions listed in the bsd.default-versions.mk.
*** Bug 287408 has been marked as a duplicate of this bug. ***
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.
(In reply to Charlie Li from comment #24) > 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. Is this something others (like me?) can help with? This seems like a very large change which will need to mature over a few minor releases before it's enabled by default, so I feel like we might have some runway in this space given that the support window for 3.13 has been increased by a half year vs the prior releases.