async-stripe: Determine a way to unambiguously re-export types without silent conflicts.
✔️ @arlyon here! For a fix, please see this comment https://github.com/arlyon/async-stripe/issues/154#issuecomment-1311619880. This issue is now about determining the best way to fix the aliasing issue.
Hi! I just updated from rc3 to 0.13
I’m trying to create a subscription with SubscriptionPaymentBehavior::DefaultIncomplete
When I pass SubscriptionPaymentBehavior::DefaultIncomplete to CreateSubscription (wrapping inside Option appropriately), the compiler complains that I’m passing the wrong one:
expected enum stripe::resources::generated::billing::subscription::SubscriptionPaymentBehavior
, found enum SubscriptionPaymentBehavior
I’m using stripe::SubscriptionPaymentBehavior
If I try using stripe::resources::generated::billing::subscription::SubscriptionPaymentBehavior
, the compiler complains that resources
is a private module
My features: async-stripe = { version = “0.13”, features = [“runtime-tokio-hyper”, “webhook-events”] }
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 15 (13 by maintainers)
This is partially addressed by the above but also rustc now warns on these.
Just ran into this myself. For users of the library, you can hack/workaround it by letting the compiler infer the type when deserializing the equivalent json.
For a fix on the library side, it sounds like reviewing the renaming PR has been pending for a while. Would it be a reasonable smaller fix to make the
stripe::resources::generated
module hierarchy public so that the users can import the specific, fully-qualified struct from there?Hi! There is a PR to try and dedupe a number of types but I haven’t had a chance to get round to reviewing it. In the mean time, you can clone the repo and work locally, following the pattern for
subscription
andsubscription_item
insrc/resources.rs
to manually export the conflicting types 😃https://github.com/arlyon/async-stripe/blob/7ae676e91fc9d7e002a7c8ec39db0c0313841b56/src/resources.rs#L183-L191
I made the PR, and I made another branch in that repo that has a hacky script to remove duplicates (see combine.py)
The python script doesn’t really follow some of the standards so well, but it maintains functionality. I tested it with an older cached 0.13.0-rc3 off crates.io (which is what my application uses). I also built it with cargo make openapi-install and adjusted the Makefile.toml accordingly
I’m new to this build process so please let me know if I missed anything!