Spin out the ffi module into its own crate

[pascalkuthe]

Hi,

thank you for all the great work on PyO3.
For an extremly performance (and compile-time) sensitive project of mine I am only using the ffi component of PyO3 directly (this project is also per definition really unsafe so a safe-wrapper is not that useful to me as for other projects).
Therefore I'd like to remove the dependency on PyO3 itself while still retaining access to the well maintained ffi module (to reduce compile times)

I have considered using python3-sys.
However it seems that this crate does not expose functions that are not part of the stable ABI (which I require).

To my understanding this would mostly involve moving some files around and replacing all uses of pyo3::ffi with pyo3_ffi (or whatever the name of the crate would be). While I do not know the codebase well I could prepare a PR myself it that would be desired

[davidhewitt]

Hi, thanks for asking about this. I've wondered about this split myself. You're right that it should be quite straightforward. We can even re-export pub use pyo3_ffi as ffi so that this change is completely backwards compatible on an API level.

To understand if it's really worth the additional complexity, I'd welcome a PR so we can see how much it really does improve compile times. If we can show measurable improvements, I'd be ok to see this split.

[mejrs]

Note that you can disable the macros feature, which will speed up compilation times.

If we can show measurable improvements, I'd be ok to see this split.

That's what I'm thinking as well.

[pascalkuthe]

I created a PR #2126

[davidhewitt]

Done in #2126