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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
