Support for GraalPy

[timfel]

Hi,

We would like PyO3 to work on GraalPy. Would contributions to that end be welcome?

GraalPy is getting more compatible (we can run large packages like Pytorch, scikit-learn, Flask, ...). Like PyPy, we cannot be ABI compatible to CPython, but instead extensions need to be compiled against GraalPy's implementation of the CPython API. Currently, this means we are blocked from running extensions such as cryptography, because the build will bail when the pyo3-build-config script declares error: unknown interpreter: GraalVM.

We are happy to contribute the code to make this work. Are there concerns you have or issues you foresee that we should be aware of?

[messense]

I'd be happy to accept contributions that add GraalPy support provided that it's well tested on our CI.

[kngwyu]

The project looks interesting, and I also think that supporting it is fine if it doesn't need much maintenance effort. How different is the ABI?

[timfel]

The project looks interesting, and I also think that supporting it is fine if it doesn't need much maintenance effort. How different is the ABI?

We make no effort to have a similar ABI, since that is just impossible without replicating all CPython internals (same as PyPy)

I'd be happy to accept contributions that add GraalPy support provided that it's well tested on our CI.

Ok, thanks, I will make sure to include it in the CI config.

[konstin]

that would be really cool! do you by chance have any docs explaining how you deal with differences e.g. between graalpython's GC and the reference counting exposed in the C API as pypy explains here? Could you also comment on the state of hpy and graalpython, since my understanding was that hpy is supposed to become the dedicated new, easier to implement C API at some point (even though we'll want the current c api in pyo3 until hpy matures).

[davidhewitt]

I would be happy to see GraalPy support contributed. If you support HPy and would be willing to help us bind via that, would be the most reusable for sure. If you want to bind directly to your API that's fine too, we might need to think a little to make sure pyo3-ffi doesn't get too hard to navigate.

[timfel]

do you by chance have any docs explaining how you deal with differences

We don't have docs like that. We have different C API backends, for our "native" backend our implementation strategy is basically identical to PyPy's. For our "managed" backend, we interpret LLVM bitcode instead of running anything natively, so we can just ignore refcounts because all allocations even for native extensions are handled by the JVM.

comment on the state of hpy and graalpython

We have ported around 30k lines of code (which is a little less than 30%) of NumPy to HPy. GraalPy and CPython are currently the only implementations that implement up-to-date HPy to run that port, but PyPy should not be far behind. HPy is at the point where we don't foresee any fundamental issues coming up, it's now a matter of porting more code and deciding on a case by case basis which additional C API functions we map to HPy in some way. HPy will be discussed at the language summit on April 19.

support HPy and would be willing to help us bind via that

In the context of HPy we would like to help move the bindings to that API. We would also like to have the intermediate (and much simpler) step of just supporting GraalPy via the current C API for now. My current patch is just to not bail out when recognizing GraalPy and otherwise use the same paths as for PyPy where appropriate.

if you want to bind directly to your API

We don't expose a separate API, just HPy and the CPython C API.

[davidhewitt]

Great, in which case it sounds like a reasonably small patch to support GraalPy, and that you've already got one which works? Feel free to push it as a PR and we can get that integrated.

In the context of HPy we would like to help move the bindings to that API.

Thanks - the issue describing the state of the discussion so far is #1113

[delioda79]

Is there any update on this? At this moment several packages depend on pydantic....and pydantic needs pyo3, which makes many packages not working with graalvm

[timfel]

Is there any update on this? At this moment several packages depend on pydantic....and pydantic needs pyo3, which makes many packages not working with graalvm

There is #3247 which works in our testing to run things like cryptography, safetensors, or tokenizers, but we rely on undefined behaviour and that raised some concerns. We are publishing a new version of GraalPy soon (it has already branched off in december) and that should put those concerns to rest.

pydantic also works in our internal testing in the upcoming version

[delioda79]

Ok looking forward it, I need to build something and I need essentially the openai package, which relies on pydantic-core......and it doe nsot get installed. I need to build a native image app and I want to use python instead of java

[davidhewitt]

Closing now that PyO3 0.21 supports GraalPy. I believe the pydantic release is imminent.