Re-exporting pyo3 breaks macros

[GrinningSoulGH]

I've been using a wrapper crate to sync versions of pyo3, pyo3-log and pyo3-asyncio between different lib and binary crates I'm developing. However, some of the code in macros appears to rely on pyo3 being available in the global scope (example: 21196e6). This is not the case for me, as pyo3 comes as a dependency for the wrapper crate. Could you elaborate on why that choice was made?

[mejrs]

However, some of the code in macros appears to rely on pyo3 being available in the global scope

That (series of) commit(s) made it so that pyo3 doesn't rely on the things in the user's scope. Can you clarify what you mean?

Or are you talking about macros in pyo3-log/pyo3-asyncio? If so you should file an issue there, because IMO a macro being unhygienic is a bug.

[birkenfeld]

I guess the problem is that if pyo3 is not a dependency of the current crate, the expanded code using ::pyo3::Foo will not automagically find pyo3 at the crate root.

However, previously pyo3 was still expected somewhere (crate root or current scope)...

[GrinningSoulGH]

It's not in the crate root, as you ascertained. Well, I can add it explicitly, but it makes the versions drift on every update. The question really becomes whether I can make pyo3 available in current scope under the required name ::pyo3 and not ::my_crate::pyo3, as I roughly have at the moment. And, also, whether this is an issue, as I haven't encountered that "scope" requirement with any of the crates I've used.

[davidhewitt]

I think this is one of those things where it hurts both ways around.

As the other answers say, we felt it was better to anchor the macros to the global scope rather than relying on pyo3 being defined correctly at in the current scope. This leads to fewer suprises where PyO3 (or std) can be overridden in the local scope with unexpected effects.

OTOH, I can certainly appreciate your use case wanting to write use my_crate::pyo3 to override what the macros look at. I think a number of proc macro crates are in similar positions where it's not clear what's better on this front. I'm happy with what we currently do because it's more robust, however am not against reconsidering.

[birkenfeld]

Maybe serde's approach is where we should aim at: https://serde.rs/container-attrs.html#crate

Basically, allowing #[pyo3(crate = "...")] to specify where to find the pyo3 crate.

[davidhewitt]

This is a great idea!