pyo3-asyncio into PyO3 org?

[davidhewitt]

EDIT: I've now created the fork, see https://github.com/PyO3/pyo3-async-runtimes

Hey @awestlake87, just wondering, now that PyO3 upstream is experimenting with official async support but we also anticipate that runtime integration won't be part of PyO3's main crate for a while, I suspect there will be quite an uptick in use of pyo3-asyncio. It already looks like this is the case based on comments requesting 0.21 support.

Would you be interested in transferring pyo3-asyncio into the main PyO3 organisation, so we can help maintain it for / with you?

[lumasepa]

@awestlake87 doesn't seem to be active on GitHub, his last contribution was in February. Maybe you can consider sending him an email.
https://github.com/awestlake87/pyo3-asyncio/blob/master/Cargo.toml#L5C13-L5C54

[davidhewitt]

I sent an email; will wait a bit for a response before considering further options.

[davidhewitt]

I think this evening I will set up a fork in the PyO3 organization which users can at least benefit from as a git dependency to fix the immediate problem. We can decide whether to release under the pyo3-asyncio name or come up with a new name later.

[davidhewitt]

As per #119 (comment)

While waiting for a permanent decision on what to do, I've published https://crates.io/crates/pyo3-asyncio-0-21 from a fork at https://github.com/davidhewitt/pyo3-asyncio

@awestlake87 has put a lot of effort into this library and I'd like to give then as much time as possible to state their wishes before we make any permanent action. My fork should at least get people onto PyO3 0.21, and I might repeat the upgrade for PyO3 0.22 in the near future (should be simpler).

For now, we can begin to think about:

• if we forked permanently, what name to give the fork?
• anyone willing to help maintain the fork (and maybe even the experimental async code within PyO3 👀)

[gerrymanoim]

Hey @davidhewitt - will you be publishing a 0.22 fork as well?

[davidhewitt]

Probably, yes. I have some family duties to take care of first and will probably help complete PyO3 0.22.1 patch release too before I get to this.

[davidhewitt]

We're approaching 3 months without an answer so I think it's time now to consider a permanent fork in the PyO3 organisation.

Two thoughts:
1 - is anyone willing to help offer maintenance? As you might see, I am a little overloaded right now so support on maintaining this crate will improve the quality and speed of releases for everyone.
2 - what shall we publish this fork as? I am considering pyo3-async-runtimes or pyo3-async-bridge. Ideas welcome.

[Andrapyre]

@davidhewitt , I'm happy to offer some help maintaining this. Do we have an estimation on what the effort would be to get this up to speed (say, just an upgrade to the latest pyo3 version)?

[regularkevvv]

We're approaching 3 months without an answer so I think it's time now to consider a permanent fork in the PyO3 organisation.

Two thoughts:

1 - is anyone willing to help offer maintenance? As you might see, I am a little overloaded right now so support on maintaining this crate will improve the quality and speed of releases for everyone.

2 - what shall we publish this fork as? I am considering pyo3-async-runtimes or pyo3-async-bridge. Ideas welcome.

I'd be happy to help!

[cjdsellers]

Hey @davidhewitt,

I might be able to help, depending on what that would entail. I'm keeping an eye on how this develops and considering my bandwidth. Would pyo3-async be too broad or feel native for crate naming?

[2bndy5]

what shall we publish this fork as? I am considering pyo3-async-runtimes or pyo3-async-bridge. Ideas welcome.

I'm partial to pyo3-async-runtimes because the name implies support for different async runtime implementations in rust. The name pyo3-async-bridge (and pyo3-async) seems less descriptive.

[davidhewitt]

Continued at PyO3/pyo3-async-runtimes#1