We need to support python 3.13 in this old slot because dev-util/intel-graphics-compiler still needs it. Thanks
No, we don't. We don't maintain dead slots anymore.
Should dev-util/intel-graphics-compiler users try to enable python3.12 for clang-15 then? I guess more people will hit this blocker when you are going to switch the defaults (and will probably be forwarded to this bug)
Feel free to find commits to backport Python 3.13 fixes. Note that it's broken in 17 and lower.
commit 0a2ed735524c09ba687e6abf6134d7f683e03bf7 Author: Eli Schwartz <eschwartz@gentoo.org> Date: Wed Apr 16 15:45:09 2025 -0400 llvm-core/llvm: enable py3.13 for old versions Python is currently only used for two things in llvm:15, and that is: - Test-time use of llvm-lit, see corresponding change to dev-python/lit for why it is safe to enable py3.13. Note that llvm-lit loads cfg files which are python scripts used by the test. Some unmaintained code removed in llvm:16 uses a python module removed in 3.13, but we never built it to begin with so the easiest fix is to remove it entirely so that llvm-lit does not try to load it and fail with ModuleNotFoundError. - USE=docs. We could drop docs from ancient slots, but it is just sphinx with a trivial conf.py and it does work, so we might as well allow it. Acked-by: Sam James <sam@gentoo.org> Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> commit c06bc57603d79b8bedf406d7dca53ba1a2794ceb Author: Eli Schwartz <eschwartz@gentoo.org> Date: Wed Apr 16 15:44:37 2025 -0400 dev-python/lit: enable py3.13 for old versions Tests all pass the same regardless of version. 15 and 16 do have warning messages fixed in 17 e.g.: ``` SyntaxWarning: invalid escape sequence '\s' ``` but these aren't an issue for 3.13 support and there's no specific timeline for when this will be converted to an error anyway. Hopefully whenever they decide to make this a fatal error, the final remaining desperate stragglers on llvm 15 will have been ported, but we'll see. Acked-by: Sam James <sam@gentoo.org> Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
(In reply to Sam James from comment #4) > commit 0a2ed735524c09ba687e6abf6134d7f683e03bf7 > Author: Eli Schwartz <eschwartz@gentoo.org> > Date: Wed Apr 16 15:45:09 2025 -0400 > > llvm-core/llvm: enable py3.13 for old versions llvm-core/clang is still lacking py3.13... I am not sure if it was forgotten when fixing llvm-core/llvm
Right, llvm != clang and I only looked at llvm since it was lower-hanging fruit and well tested. I think clang is going to be much more annoying because I am not sure that the random end user utilities have a reliable testsuite and even figuring out what uses python there is much harder to grep than it was for llvm. Maybe a simpler solution would be to add a USE flag to disable tools that nobody cares about. It won't affect intel-graphics-compiler if run-clang-tidy isn't actually installed.
(In reply to Eli Schwartz from comment #6) > Maybe a simpler solution would be to add a USE flag to disable tools that > nobody cares about. It won't affect intel-graphics-compiler if > run-clang-tidy isn't actually installed. That won't let you add it without testing.
(In reply to Michał Górny from comment #7) > (In reply to Eli Schwartz from comment #6) > > Maybe a simpler solution would be to add a USE flag to disable tools that > > nobody cares about. It won't affect intel-graphics-compiler if > > run-clang-tidy isn't actually installed. > > That won't let you add it without testing. I'm not sure what you mean. It would obviously mean you could then conditionalise PYTHON_REQUIRED_USE, so nobody cares if it doesn't support older Python.
The Python stuff seems spread out across a few USE (extra, static-analyzer) already. Not sure how feasible it is to split those bits into a separate package (seems silly to have to rebuild Clang on Python changes).
(In reply to Michał Górny from comment #7) > (In reply to Eli Schwartz from comment #6) > > Maybe a simpler solution would be to add a USE flag to disable tools that > > nobody cares about. It won't affect intel-graphics-compiler if > > run-clang-tidy isn't actually installed. > > That won't let you add it without testing. The purpose of this bug report claims to be "add py3.13 support to clang 15. It is not. It is actually "intel-graphics-compiler cannot be installed by default if it depends on clang 15 and the latter pulls in a python that isn't compatible with PYTHON_TARGETS". It is my humble suggestion that the latter is an easier problem to solve than the former, at the cheap cheap cost of adding some USE conditionals to clang and then cheerfully refraining from building USE=python-tools (or whatever you wish to call it). That makes python support "someone else's problem". Maybe one day we will find someone who actually cares about parallel installation of 6 different versions of run-clang-tidy, one for each version of clang -- but that person isn't me, and if that person ever materializes outside of a Fantasy novel (I don't think Sci-Fi is powerful enough to locate such a person), then well, we've found our volunteer for testing py3.13 support, and I wish them all the best from a safe distance.
