Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TASK: determine status of clang wrt python3 JIT #207

Open
yselkowitz opened this issue Nov 22, 2024 · 3 comments
Open

TASK: determine status of clang wrt python3 JIT #207

yselkowitz opened this issue Nov 22, 2024 · 3 comments
Assignees
Labels
cleanup Removal of deprecated or unwanted packages question Further information is requested

Comments

@yselkowitz
Copy link
Member

What does the ELN SIG need to do?

The new JIT in Python 3.13 has clang as a build (but not runtime) dependency. Unfortunately, the code is locked to a particular version; 3.13 uses llvm/clang 18, main (the future 3.14) uses 19. Therefore, a clang18 compat package is needed to build the JIT in Fedora 41 (which normally uses llvm/clang 19). On Fedora this isn't a big deal, but on ELN this is pulling in llvm18/clang18 into the buildroot (all other consumers have already been ported to the current 19).

For RHEL though this seems untenable. The default python3.Y package must remain buildable for the entire lifetime of RHEL, but llvm is continuously updated to newer versions. RHEL 10 has Python 3.12 as default, so there is no precedence yet, but this will come up should any additional versions be provided in parallel (albeit with shorter scope).

Therefore, we need clarification on these points:

  • Should the JIT be enabled in RHEL/ELN builds of python 3.13+?
  • If so, will a llvm compat version be kept in the buildroot for as long as necessary to continue building the JIT?
  • Or, will support for newer llvm versions be backported? Can that even be done safely, particularly over such a long span?

/cc @hroncok

@yselkowitz yselkowitz added question Further information is requested cleanup Removal of deprecated or unwanted packages labels Nov 22, 2024
@yselkowitz
Copy link
Member Author

FTR, the changes to port the JIT from 18 to 19 are extensive: python/cpython#125499

@hroncok
Copy link

hroncok commented Nov 22, 2024

Thanks for asking the question, this is definitely something that needs to be solved.


The default python3.Y package must remain buildable for the entire lifetime of RHEL, but llvm is continuously updated to newer versions.

That's definitely something we need to consider when we decide whether or not c11s will have Python JIT enabled. Or when we'll add Python 3.14 to c9s/c10s.

Should the JIT be enabled in RHEL/ELN builds of python 3.13+?

The CPython JIT is experimental, so it definitively isn't "enterprise material". At this point, I would not enable it in RHEL.

On the other hand, ELN is a place to experiment for future RHEL. Chances are that the JIT will become more stable in time for RHEL 11 (which will very likely contain Python 3.15/3.26).

So I'd like to keep this enabled in ELN for now (if it's not a big deal) and revisit this in 2 years. I would certainly not want to pull some old LLVM version to RHEL-proper, but but having it in ELN "for now" is probably OK.

If so, will a llvm compat version be kept in the buildroot for as long as necessary to continue building the JIT?

If so, then yes.

Will support for newer llvm versions be backported?

Time will tell. No idea yet.

@hroncok
Copy link

hroncok commented Dec 6, 2024

Upstreams considers supporting ranges of LLVM versions: https://discuss.python.org/t/llvm-19-for-jit-on-3-13-maybe-19-for-3-14/73425/2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cleanup Removal of deprecated or unwanted packages question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants