Perhaps this should just be built-in to eventlet?

[itamarst]

1. Less dependencies for users to manage.
2. eventlet could just default to asyncio hub, cause why not, requiring less setup by users.
3. Less project management overhead.

[4383]

The main problem that I can see with the proposed approach, is that only users with the eventlet in the right version would be able to migrate. Maybe some users are stuck with a particular version of eventlet and sticking to it is mandatory for them, so likely they are not able to upgrade their requirements, and so the migration would remain impossible for them.

Keeping aiohub as a standalone deliverable would allow to deal with this kind of scenario, which, IMHO, are legion through the Python ecosystem.

However, I agree that one project management would trigger less overhead. On the other side, two explicitly separated scope would reduce the complexity and avoid entangled things. It would also reduce unexpected side effect on eventlet, at least, for all projects not relying on aiohub.

Thoughts?

@jeckersb: any opinion?

[4383]

aiohub would be agnostic to the eventlet version in use at runtime. All eventlet versions would be compatible with aiohub.

[4383]

CC @jayofdoom: Would appreciate to have your thinking here.

[jayofdoom]

It's hard for me to imagine a scenario where a codebase exists that is:

• Sufficiently flexible to use an aiohub-style migration method AND
• Unable to upgrade to the latest eventlet version

I have been slightly perplexed the whole time why we've been going forward with a separate library, but given evented programming is not my forte I've tried to mostly play a supporting role. I think many of us have experience of how much pain the explosion of testing matrices can cause; do we really intend on supporting/testing aiohub with many versions of eventlet?

I suspect the reality is it's unlikely that aiohub will be a well-tested option outside of narrowly limited parameters even if it's a separate library, and that makes me strongly lean in the direction of leaving it integrated in eventlet and not as a separate library.

[itamarst]

Beyond the can't-upgrade-eventlet argument, the other argument brought up was 'two explicitly separated scope would reduce the complexity and avoid entangled things'. I really don't think that's the case, especially if we don't make asyncio hub the default, in the good scenario it's just some extra modules you can choose to use, or not. (In the bad scenario where this migration requires changes to eventlet, the discussion is moot: we'll have to integrate it.)

From a maintainer perspective, the easiest way to know a hub is working with eventlet is to run the eventlet test suite... which is much easier in the eventlet repo.

[4383]

From a maintainer perspective, the easiest way to know a hub is working with eventlet is to run the eventlet test suite... which is much easier in the eventlet repo.

The eventlet test suit could be also run with aiohub through a cross-testing job. That wouldn't be an issue.

I was not thinking supporting all the versions of eventlet in aiohub, but at least the most recents.

Another, point that I see to moving aiohub to eventlet is that this will contradict a bit our maintenance goal, and our decision to move to legacy mode. aiohub in eventlet would be seen as new features, which is contradict the no new features statement.

Anyway, even with this side question, I think you are globally right on the other aspects, and I think your arguments hold water.

I join your position, and I think merging the both project could encourage people to upgrade to the recent versions of eventlet, and, then, encourage people to migrate to asyncio in a second time.

As we surely not yet seen all the big picture related to this topic, I'd suggest to keep this issue opened, to let's time to other maintainers to react.

The next two weeks will be quiet, we could officialize the decision to move inside eventlet early in 2024.

Thoughts?

[itamarst]

Sounds good.

[itamarst]

I discovered some prior art:

• https://gist.github.com/miguelgrinberg/829a20792d7283ae27b1f6a390c378b9 - seems to kinda work already. I emailed author about licensing to MIT so we can use it.
• https://pypi.org/project/aioeventlet/ - wrong direction, asyncio running on top of eventlet.

[jayofdoom]

I'd suggest nominally getting buy-in, or at least an explicit ping, on some of the remaining eventlet maintainers from the existing community before just foisting this over there. Might be worth opening an issue and giving a place for objections to be raised rather than treat it as a fait accompli. (Especially with the promise to the outgoing maintainer that we'd ensure eventlet would be handed off if/when OpenStack migrated off it.)

[4383]

Nobody raised any concerns or objections, we all agree to move aiohub feature as built-in eventlet features, so let's close this discussion.