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)
__________________________________________________________________________
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
