Open Stack

On 5/4/15 6:48 PM, Thomas Goirand wrote:
> I don't see what it would break. If I do:
>
> Package: python-mysqlclient
> Breaks: python-mysqldb
> Replaces: python-mysqldb
> Provides: python-mysqldb
>
> everything is fine, and python-mysqlclient becomes another 
> implementation of the same thing. Then I believe it'd be a good idea 
> to simply remove python-mysqldb from Debian, since it's not maintained 
> upstream anymore.
>
>> It is also imprudent to switch
>> production openstack applications to a driver that is new and untested
>> (even though it is a port), nor is it necessary.
>
> Supporting Python 3 is necessary, as we are going to remove Python 2 
> from Debian from Buster.
I don't know debian but the approach would be that something like the 
"mysqlclient-py3k" package applies to Python 3 only.



>
>> There should be no
>> reason Openstack applications are hardcoded to one database driver.
>
> If they share the same "import mysqldb", and if they are API 
> compatible, how is this a problem?
how do you know they are API compatible?   This is in fact exactly where 
this approach can become a huge problem.   No MySQL drivers I've ever 
used are fully API compatible with any of the other ones. *all* of them 
have subtle and not-so-subtle differences in behavior.  That mysqlclient 
is now a fork means it will begin to diverge, and as issues come up to 
which their resolution requires even more subtle or not-so-subtle 
changes in behavior, these differences will only continue to grow.

 From a SQLAlchemy perspective this would be much easier to maintain as 
a new sub-dialect.  I've proposed that they change their name: 
https://github.com/PyMySQL/mysqlclient-python/issues/44 .  However, the 
maintainers are not going for it, so I guess that isn't going to happen.




>
>> The
>> approach should be simply that in Python 3, the mysqlclient library is
>> installed instead of mysql-python.
>
> So, in Python 3, we'd have some bugfixes, and not in Python 2? This 
> seems a very weird approach to me, which *will* lead to lots of issues.
I've asked three times now to please show the bugfixes that are 
needed.    Show me the issues that aren't being fixed, and then I will 
be convinced and begin the process of pushing here at Red Hat to make 
the same packaging changes such that our customers will no longer be 
able to use the original MySQLdb.     We're talking about an instant, 
systemwide replacement of one MySQLdb implementation for another and I 
just think that is high risk.


>> B. use pymysql.    All other performance arguments are moot right now as
>> we are in the basement.
>
> Eventlet has to die, we all know it. Not only for performances reason. 
> But this is completely orthogonal to the discussion we're having about 
> having Python 3 support. Please don't stand on the way to do it, just 
> because we have other (unrelated) issues with Eventlet + MySQL.
>
> Switching to mysqlclient is basically almost "free" (by that, I mean 
> effortless), if I understand what Victor wrote. The same thing can't 
> be said of removing Eventlet or switching to pymysql, even though if 
> both may be needed. So why add the later as a blocker for the former?
Well, switching to pymysql *is* just as effortless IMHO, and in fact 
*more* effortless because it can be done impacting only individual 
applications at a time, rather than forcing it on everything at once.  
    SQLAlchemy has a dialect for PyMySQL already which is well 
maintained and well tested.  We change the database URL in projects to 
include "mysql+pymysql", update requirements.txt, distros add their 
packages like they have to anyway, and we're done.     From my view, if 
we're going to switch DBAPIs then PyMySQL would be it - if we're going 
for "bug fixes in the DBAPI", the "doesn't support eventlet" is the 
*biggest* bug.

But again, I really want to see what the critical issues in MySQLdb are 
that are holding us back.   If there are really fixes and features we 
need in Py2K then of course we have to either convince MySQLdb to merge 
them or switch to mysqlclient.   At the moment though I need to see the 
evidence for me to really buy this argument.