Open Stack

On 05/05/2015 08:41 PM, Mike Bayer wrote:
>
>
> 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?

According to Victor, that's what the author of the fork says. That's 
also what he wants, as per the issue 44 which you raised (the 
mysqlclient upstream wants it to be a drop-in replacement for mysqldb, 
to help distributions to better switch to Python 3).

> 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.

I agree. Which is exactly why we don't want one package for Py2, and the 
other one for Py3.

> From a SQLAlchemy perspective this would be much easier to maintain as
> a new sub-dialect.

Best for SQLA and everyone else would be a re-merge as a single project. 
Either that, or just mysqlclient takes over completely mysql-python in 
PyPi, just like you suggested in the github issue 44. I'd love to see 
one or the other happen. The later could be decided by a PyPi 
administrator, given the fact that the mysql-python maintainer is 
unresponsive. Have you tried to approach someone with such rights at PyPi?

Though if it doesn't happen, as you wrote it's going to be hell for you 
to test against both implementation. Maybe then the only choice you have 
is to decide to use only one of them (and mysqlclient seems the best of 
both).

I by the way found methane very reasonable in his replies

>>> 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.

Yourself, you wrote that there was some bugfixes and subtle differences, 
didn't you?

> 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.

IMO, since that's a fork, the risk isn't greater than just upgrading 
from one version to next for any given package.

>> 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.

Really? If it's that simple, then please start doing this, and let's 
happily switch to PyMYSQL for Liberty.

> But again, I really want to see what the critical issues in MySQLdb are
> that are holding us back.

The main motivation is the lack of support for Python 3.

> 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.

Given the "no reply in 6 months" I think that's enough to say it: 
mysql-python is a dangerous package with a non-responsive upstream. 
That's always bad, and IMO, enough to try to get rid of it. If you think 
switching to PyMYSQL is effortless, and the best way forward, then let's 
do that ASAP!

Cheers,

Thomas Goirand (zigo)