Change the import name from MySQLdb to mysqlclient to avoid conflicts, or taking over "MySQL-python" on PyPI #44
Comments
|
There are many products depending MySQL-python. And MySQL-python can't be compiled on some new distributions. |
so what? those distributions should only distribute mysqlclient.
what application hardcodes the name MySQLdb inside of it, and if so, how is that not a bug on their end?
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. |
|
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. |
|
@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. |
How people run Trac with MySQL without rewriting imports?
Trac. And Django only support MySQL-python officially.
I think there are more disaster if distribute use other name. People may be required to rewrite
I stop this project happily when MySQL-python become maintained again and support PY3 well. |
I don't know how difficult to test both with tox.
I see. mysqlclient should provide way to distinguish from MySQL-python even if using same package name. |
|
PyMySQL has 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 Another way is creating another fork. It fixes only build&install issue and keeps behavior including bug. |
|
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. |
|
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. |
|
My most desirable future is merging mysqlclient into MySQL-python. But I want to help Debian, Ubuntu, Redhat, CentOS and OpenStack moving to Python 3. First of all, I'll contact to @farcepest and @paultag (https://lists.debian.org/debian-devel-announce/2015/04/msg00005.html ). |
|
@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. |
|
I found bug about this problem. |
|
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...). |
|
I want to discuss with OpenStack, Debian and RedHat developers to change or not change import name... |
|
I think it makes perfect sense to issue a take over request (if it's possible) since no life sign of MySQLdb have been shown in over a year, I've tried to contact @farcepest as well without any success. The library have 500k monthly downloads, not being able to patch security issues or bugs is critical. I agree we should send one last mail to @farcepest and CC debian-python and/or distutils-sig mailing lists. @methane let me know if you don't have time, and I'll try to push this. |
|
I just got contact with Andy and he will look into how we can solve the ownership tomorrow. |
|
@tiwilliam any update? |
|
Nope, he never came back. Got contact on Google+. |
|
http://sourceforge.net/p/pypi/support-requests/ is where the owner of the new package can request a takeover of the existing name |
|
"And Django only support MySQL-python officially." This is wrong. According to https://docs.djangoproject.com/en/1.8/ref/databases/ "mysqlclient is a fork of MySQLdb which notably supports Python 3 and can be used as a drop-in replacement for MySQLdb. At the time of this writing, this is the recommended choice for using MySQL with Django." |
|
@rbu Thank you for your imformation. |
|
what about mysql-connector-python /cc @geertjanvdk |
|
If Oracle want to take over MySQL-python on PyPI, and they will upload at least binary wheel for windows and pip installable packeges for unix, I'm +1 for it. This project is continuous maintenance of MySQL-python 1.2.x. |
|
@methane I don't think Oracle have any intentions of uploading anything to PyPI. You should push for PyPI to make the PyMySQL team owners of the names on PyPI. |
|
-10000000 million billion for giving anything whatsoever to Oracle. |
|
Currently, the PyPI license gives issues when uploading GPL'ed software. Would be freaking great if Connector/Python is on PyPI, but nothing Oracle can help.. 'MySQL-Python' and 'PyMySQL' are not Oracle's and are not related to Connector/Python. |
|
PyPI is 100% compatible with the GPL On 1 Aug 2016 7:15 pm, "Geert Vanderkelen" notifications@github.com wrote:
|
|
@geertjanvdk what issue do you see in uploading GPL software to PyPI? There's even a trove classifier: License :: OSI Approved :: GNU General Public License v2 (GPLv2) |
|
It seems like this may have been halfway resolved in any event, but I just thought I'd weigh in here re: the root cause of the problem (esp. since it sounds like Donald was not made aware of the issue). This is Jim Wright, Oracle's Chief Architect for Open Source Policy, Strategy, Compliance and Alliances. I am an attorney for Oracle as well as an architect and I'm not sure if you folks are represented in this matter - if you are, the Rules of Professional Conduct for attorneys are such that I cannot communicate with you without your counsel's consent, so please have them email me at jim.wright@oracle.com. (And if you're not represented, please email me yourself to that effect if you'd like to discuss.) The terms of use at https://www.python.org/about/legal/ provide in pertinent part as follows: "third party content providers grant the PSF and all other users of the web site an irrevocable, worldwide, royalty-free, nonexclusive license to reproduce, distribute, transmit, display, perform, and publish such content, including in digital form" Unfortunately this does not say the PSF and its users are getting a license under the GPL. In fact, the terms of that license grant are clearly incompatible with the GPL (e.g., the GPL is not an irrevocable license - it contains an express termination provision that is invoked if you do not comply with its terms). If content providers are bound by those terms to begin with, for someone to upload GPLed content under that license probably either means they are violating the GPL (e.g., if someone else uploaded Oracle's GPL licensed content), or, if they are the sole copyright holder, they are granting the PSF and all its users a different license than the GPL to that material. That doesn't work for the obvious reasons. If I'm informed correctly, this issue with the terms of use was raised with the PSF some time ago but it sounds like this may have gotten lost in the noise - if you'd like to discuss how to fix it, I would love to help in whatever way I can, and as soon as the terms are fixed, we would be happy to maintain MySQL Connector/Python on PyPI. -- Jim |
|
@JimAtOracle well this changes everything |
|
Here to help! :) |
|
I'm happy about two things: 1) I am not disappeared; and 2) the "I can't" was explained by Jim; I'll be sleeping well tonight. |
|
Although @JimAtOracle you do own copyright to mysql-connector-python, so you could assign such a licence |
|
(if you so wished) |
|
@geertjanvdk I'm hearing a "won't" not a "can't", which I guess complies with PyPI policy |
|
did @JimAtOracle just delete his message? come on, guys |
|
Hmm, it appears that @JimAtOracle deleted their comment, with respect to that I won't quote it here. I am not a Lawyer and I don't make decisions about the legal side of PyPI, I just run the site itself :) The current ToS was crafted by @VanL and I can only assume that he is of the opinion it doesn't clash, since I'm pretty sure he does not want to prevent GPL software from being uploaded to PyPI. However, this is a sufficiently nuanced discussion that I suspect Github issues is not the correct place to hash out the nuances of law here. If Oracle has not yet already, please reach out to the PSF board (psf@python.org) and indicate why you believe you can't upload to PyPI. The board is better equipped to handle this than I suspect I, and a bunch of other folks in a GitHub issue are. If you want you can CC me (donald@python.org) or you can just reach out to them directly. |
|
Redacted |
|
@graingert now oracle is going to send you a dmca notice |
|
I did not delete my comment. I want to respond to everyone but can't unless/until someone from the PSF confirms they are not represented, or their counsel OKs me talking here. |
|
me? But I'm nothing to do with github |
|
@zzzeek Apparently there was momentary hiccup with my account. @graingert @dstufft Assuming VanL is your lawyer, please have him follow up with me. I can't discuss further with you here unless/until he OKs us talking. |
|
Guys, Jim messaged me something went wrong with his GitHub account, but "comment will no doubt reappear". |
|
Is deleting a comment you were not allowed to send tampering with evidence? On 1 Aug 2016 22:55, "mike bayer" notifications@github.com wrote:
|
|
Ok, I think my account has been reactivated... pretty funny to see the conjecture/responses though. I have contacted the PSF board as per Donald's suggestion and hopefully we can get the terms questions ironed out. Cheers all. |
|
To be clear, Van is not my lawyer, nor do I have a lawyer at all, at least to my knowledge. I also don't really have a horse in this race :) I don't care what Terms PyPI has as long as they allow us to achieve our mission nor do I use MySQL Connector. I mostly just develop and operate PyPI on a technical level as a volunteer, on a legal level it's all the PSF. That being said, I don't think it's very useful to discuss it with me :) I am not a lawyer, Van once tried to explain how the PyPI ToS interacts with the license already on software to me and I got confused very quickly. Although I recall a previous time when Van went into a bit of detail about the license when there was a similar question about the terms of the license. I don't really understand what Oracle's concern is so I don't know that it's the same, or even really related, but in case it's interesting you can view the thread archives at https://mail.python.org/pipermail/python-legal-sig/2013-March/thread.html. Anyways, it sounds like things are in good hands, and hopefully Jim and the PSF can get things hashed out to the point everyone is happy and there's nothing stopping Oracle from uploading to PyPI. |
|
tl;dr
|
methane
changed the title
|
I'm sorry about I misunderstood like "Both of Oracle and I claim taking over MySQL-python on PyPI." @graingert Are you PyPI maintainer? |
|
@methane I wanted to sort out the other python mysql DB API library as a sort of rider on this issue. With the aim to get them all under one umbrella in one go |
|
@graingert im not sure if i understand that statement. are you saying you want all MySQL DBAPI libraries to be maintained by one group ? how would that even be achievable, if someone decides to write a new DBAPI for MySQL... |
|
Can we please open a separate issue for discussing |
|
No, only the unmaintained ones On 2 Aug 2016 07:14, "William Tisäter" notifications@github.com wrote:
|
|
@graingert MySQL Connector/Python is maintained project. Could you go
|
|
This issue is too long. I can't read whole thread already. |
|
PEP 541 is accepted. But this issue is too long and old. |
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.
The text was updated successfully, but these errors were encountered: