Add PyPy3.11

[mattip]

Support PyPy's python3.11. It is not officially released yet, but I wanted to be sure PyO3 works.
I am testing this branch elsewhere. Until there is an official release, I set the PR to use the nightly builds.

You may wish to hold off on merging this until the official release, that is fine with me.

Also I dropped PyPy3.9 since we no longer support it. Nothing has changed so it should JustWork(tm)

I had help from the discussions, thanks!

[mattip]

Hmm. There is a unused declaration error. Any suggestions how to fix that?

 error: unused import: `c_char`
   --> pyo3-ffi/src/cpython/abstract_.rs:2:20
    |
  2 | use std::os::raw::{c_char, c_int};
    |                    ^^^^^^
    |
    = note: `-D unused-imports` implied by `-D warnings`
    = help: to override `-D warnings` add `#[allow(unused_imports)]`
  
  error: unused import: `std::os::raw::c_char`
   --> pyo3-ffi/src/cpython/genobject.rs:6:5
    |
  6 | use std::os::raw::c_char;
    |     ^^^^^^^^^^^^^^^^^^^^
  
  error: unused import: `libc::size_t`
   --> pyo3-ffi/src/cpython/objimpl.rs:1:5
    |
  1 | use libc::size_t;
    |     ^^^^^^^^^^^^
  
  error: could not compile `pyo3-ffi` (lib) due to 3 previous errors

[Icxolu]

These occur because with this there are new cfg combinations possible that weren't possible before (and therefore not tested for). To get rid of the warnings you need to add cfgs to them, so we only import them when they are needed.

In the order from the error above, I think these should be 🤞:

• #[cfg(any(all(Py_3_8, not(any(PyPy, GraalPy))), not(Py_3_11)))]
• #[cfg(all(not(PyPy), not(GraalPy), Py_3_11))]
• #[cfg(any(all(not(PyPy), not(GraalPy)), not(Py_3_11)))]

[mattip]

Thanks, let's try it

[mattip]

Yup, that seems to have done the trick. Is there anything else I should try? I will mark this as "draft" since it can wait for the release to be merged.

[davidhewitt]

Thanks, I added a label so that the full CI will trigger if you push again to this branch. This should execute more PyPy3.11 jobs and give better feedback.

Aside, if pypy/pypy#3836 ever gets resolved it will vastly increase the amount of testing of PyPy we can do here, because we have an absolute heap of tests which use Py_Initialize to spawn interpreters and run basic checks. I think it's out of scope for me to find time to work on that for the foreseeable future sadly.

[davidhewitt]

Please rename this to 4760.packaging.md - we put the packaging section at the top so easier for users to notice this.

[mattip]

Unfortunately we are also unlikely to implement Py_Initialize. To do it properly would require first refactoring the startup code in pypy/interpreter/app_main.py and pypy/module/sys to use a CPython-like startup sequence with a configuration object.

[mattip]

rebased off main to clear some conflicts