Change the import name from MySQLdb to mysqlclient to avoid conflicts, or taking over "MySQL-python" on PyPI

[zzzeek]

It is destabilizing to expect that a particular application that wishes to make use of "mysqlclient" under Python 2K must therefore in one step use mysqlclient for all applications that share the same virtual or actual Python environment. it should be be possible for some applications to use the traditional MySQLdb and for others to use mysqlclient.

Other DBAPIs that began as forks or ports of others have followed this practice, e.g. fdb is a port of kinterbasdb, psycopg2cffi is a pypy port of psycopg2, etc. It only creates confusion and reduces options when two totally different codebases share the exact same module name. Especially on Linux distributions it means that two packages will necessarily overwrite each other and be in conflict.

[methane]

There are many products depending MySQL-python. And MySQL-python can't be compiled on some new distributions.
In such cases, pip install mysqlclient helps people want run application without modifying it.
It is like distribute and pillow overwrite setuptools and PIL package.

[zzzeek]

And MySQL-python can't be compiled on some new distributions.

so what? those distributions should only distribute mysqlclient.

In such cases, pip install mysqlclient helps people want run application without modifying it.

what application hardcodes the name MySQLdb inside of it, and if so, how is that not a bug on their end?

It is like distribute and pillow overwrite setuptools and PIL package.

distribute's overwrite of the "setuptools" name was a disaster and they had to undo it, once setuptools became maintained again. PIL has been a totally dead project for much much longer than MySQLdb.

[zzzeek]

also, one thing this name collision does is make it very difficult and inconvenient for me to test SQLAlchemy against both packages. It means that for me to test one or the other, I need to use entirely separate virtual environments. Dropping support for mysql-python from SQLAlchemy is not an option. It is also not safe to assume these two libraries have identical behavior; that's actually impossible, as MySQL-Python has bugs that this library promises to fix. SQLAlchemy has behaviors and workarounds that may no longer apply to mysqlclient, or may need behaviors and workarounds that are specific to mysqlclient. The testing burden for downstream libraries here increases.

[zzzeek]

@methane - have you tried contacting @farcepest to request being given access to take over https://pypi.python.org/pypi/MySQL-python/ on Pypi ?

[methane]

@methane - have you tried contacting @farcepest to request being given access to take over https://pypi.python.org/pypi/MySQL-python/ on Pypi ?

@rbu sent mail about it on 2014/12.

I have not sent such mail yet since I'm not good at writing English to write modest mail.

[methane]

so what? those distributions should only distribute mysqlclient.

How people run Trac with MySQL without rewriting imports?

In such cases, pip install mysqlclient helps people want run application without modifying it.

what application hardcodes the name MySQLdb inside of it, and if so, how is that not a bug on their end?

Trac. And Django only support MySQL-python officially.
PeeWee, SQLAlchemy and other ORMs should support new package name too.

It is like distribute and pillow overwrite setuptools and PIL package.

distribute's overwrite of the "setuptools" name was a disaster

I think there are more disaster if distribute use other name. People may be required to rewrite import setuptools in setup.py to install software on platform setuptools doesn't support.
Using different package name for drop-in replacement of unmaintained library requires efforts to many people (including not Python programmer).

and they had to undo it, once setuptools became maintained again.

I stop this project happily when MySQL-python become maintained again and support PY3 well.

[methane]

also, one thing this name collision does is make it very difficult and inconvenient for me to test SQLAlchemy against both packages. It means that for me to test one or the other, I need to use entirely separate virtual environments.

I don't know how difficult to test both with tox.

It is also not safe to assume these two libraries have identical behavior; that's actually impossible, as MySQL-Python has bugs that this library promises to fix. SQLAlchemy has behaviors and workarounds that may no longer apply to mysqlclient, or may need behaviors and workarounds that are specific to mysqlclient.

I see. mysqlclient should provide way to distinguish from MySQL-python even if using same package name.

[methane]

PyMySQL has install_as_MySQLdb() to replace MySQL-python.
But it's inconvenient since adding import pymysql; pymysql.install_as_MySQLdb() in right place is difficult.

So I don't want to remove "pip installable drop-in replacement for MySQL-python" feature.

I'm thinking about providing "mysqldb-mysqlclient" package which provide MySQLdb package. It only do import mysqlclient; mysqlclient.install_as_MySQLdb().
When people want separated package, just "pip install mysqlclient".
When people want drop-in replacement, "pip install mysqldb-mysqlclient".

Another way is creating another fork. It fixes only build&install issue and keeps behavior including bug.

[zzzeek]

Well Trac would need to support dynamic database DBAPI names. I'd consider it a bug in Trac. They support multiple backends like SQLite and Postgresql so it isn't like they are using the special non-DBAPI features of MySQLdb.

Providing an alternate package is another approach. But mostly, I'd like @farcepest to let you just take over the Pypi entry. If he's unresponsive on this, then it seems most people are already preferring that mysqlclient just walk over the MySQLdb import name even though I'd prefer we didn't.

[zzzeek]

Also, if you want to reach out to @farcepest and are concerned about English, send me what you want to send and I can suggest edits.

[methane]

My most desirable future is merging mysqlclient into MySQL-python.
This is why I didn't change package name.

But I want to help Debian, Ubuntu, Redhat, CentOS and OpenStack moving to Python 3.
Especially, I hope Ubuntu 16.04 LTS and Debian Stretch are completely moved to Python 3.
If current status of MySQL-python and mysqlclient makes difficult to moving Python 3,
I'll give up about merging back and change package name.

First of all, I'll contact to @farcepest and @paultag (https://lists.debian.org/debian-devel-announce/2015/04/msg00005.html ).

[rbu]

@zzzeek, I emailed @farcepest five months ago on December 3, 2014 and again 3 months ago on February 3, 2015 simply to request input or give a statement what his intentions for the project are. There was no response. @lecram and @methane were in CC.

I think the best course of action would be to request a project takeover on PyPI.

@methane, I agree with @zzzeek on the naming issue. It should be possible to maintain the fork with a different module name and have a second package on PyPI that just provides the compatibility drop-in.

[methane]

I found bug about this problem.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768096

[thomasgoirand]

Methane,

FYI, and if you didn't get it, the bug ends with mysqlclient being uploaded as a replacement for python-mysqldb in Debian experimental. In other words, the maintainer of the python-mysqldb package decided to replace mysql-python by mysqlclient.

Given the lack of response from the maintainer of mysql-python, I would suggest to go ahead with the take over of mysql-python in PyPi, though IMO, you should make a last attempt at contacting him again, explaining your intentions. Best would be to do this with CC to a public mailing list, and give him an ultimatum (after X number of weeks without reply, here's what is going to happen...).

[methane]

I want to discuss with OpenStack, Debian and RedHat developers to change or not change import name...