Drop support for mysqlclient

[laurent-indermuehle]

I propose to drop support for mysqlclient in a later major release (4.0.0 or 5.0.0).

Pros

• Less tests to write and maintain
• Less tests in the matrix resulting in faster CI runs
• Less variations of behavior of our plugins as I'm sure we haven't covered them all with our tests (encoding? error handling? etc)
• Ability to use features only availables in PyMySQL like:
  • cursor._result.warning_count
• Motivate us to contribute upstream as PyMySQL is 100% python while mysqlclient has parts in C

Cons

• mysqlclient is faster (but from Ansible, do we really need speed? I don't think so)
• Users of mysqlclient unhappy to be forced to change.

If we go ahead, here is a possible course of actions (Thanks @Andersson007 for the list):

• 1.1 We'll invite people to the discussion via Bullhorn
• 1.2 We'll invite our contributors and maintainers individually we have contacts of
• 2. After discussions, open a vote based on the result
• 3. If it's positive, we'll create an issue (and a milestone if we decide to drop it in 5.0.0)
• 4. We also add a warning to the code triggered when people use mysqlclient asking them to switch to PyMySQL
• 5. That PR will also contain a major_change entry just as an announcement
• 6. In 4.0.0, we'll drop support not changing the code but just the warning that the connector is not supported.
• 7. We'll remove corresponding integration / unit test parts
• 8. Later we can purge the code from mysqlclient code

Please participate in the comments, your feedback is import to help us do the right thing. I'll report your pros and cons above.

[Andersson007]

I support the idea
@betanummeric @rsicart @Jorge-Rodriguez @markuman ideas?

[betanummeric]

From a maintainer perspective having only one driver would be nice.
But some users may be happy with mysqlclient and not willing to switch the driver and get slower.
Some usage statistics would be helpful to see how many people us mysqlclient vs PyMySQL. I guess we don't have those numbers.
I'm mostly using PyMySQL.
...so no clear opinion from me.

[markuman]

Mostly I use also PyMySQL, because the setup is faster and easier.
Talking about "slower". Does anyone makes some benchmark, how much slow means "slower"?

[laurent-indermuehle]

I think speed is irrelevant for Ansible. You need that for a Django app with many concurrent users interacting all at once with the database. Ansible is super slow by nature and don't make that many calls to the database per playbook run.

I often switch between PyMySQL and mysqlclient when I run integrations tests on my 10+ years old desktop (Core i5 4690K). So I can say that the difference is undistinguishable despite the fact that our tests do much more calls to the database than a normal playbook would do!

In the last CI run, you can see those durations:

• Integration (Python: 3.10, Ansible: stable-2.14, DB: mariadb 10.5.18, connector: mysqlclient 2.1.1 : 8 min 25 sec
• Integration (Python: 3.10, Ansible: stable-2.14, DB: mariadb 10.5.18, connector: pymysql 1.0.2) : 8 min 57 sec
• Integration (Python: 3.10, Ansible: devel, DB: mysql 8.0.31, connector: mysqlclient 2.1.1) : 13 min 07 sec
• Integration (Python: 3.10, Ansible: devel, DB: mysql 8.0.31, connector: pymysql 1.0.2) : 12 min 26 sec

Thought I wouldn't use Github actions as a benchmark due to its inconsistences (some jobs run in 14 minutes, others in 2 hours) I think it prove the point that the connector doesn't influence much the total time to run a playbook.

[Andersson007]

Was thinking about it a bit. I guess in highload complex systems where performance really matters devs usually separate app servers from DBs, so the apps connect to the DB remotely, i.e. the local driver on DB server isn't involved.
But it's an assumption.

Anyway, the plan assumes that we'll declare that we'll stop testing against mysqlclient and won't be changing any related code for some significant time (for a year say). At the same time people will get warning if they use the connector.
If there are a lot of complains, we can start supporting it again by just reverting that future PR that removes testing.
It can bring some pain with new features' code though.

The maintainers' happiness is as important as users' one:) No happy maintainers, no alive good supported project:)