Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change package name or not #232

Closed
methane opened this issue Apr 17, 2018 · 10 comments
Closed

Change package name or not #232

methane opened this issue Apr 17, 2018 · 10 comments

Comments

@methane
Copy link
Member

methane commented Apr 17, 2018

PEP 541 is accepted.

But I think most users already switched from MySQLdb to mysqlclient.
So, what should we do for now?

  • a. Claim taking over MySQLdb on PyPI
    • a1. Release package for both name
    • a2. Remove mysqlclient and continue MySQLdb
  • b. Keep current package name.
    • b1. Don't change import name.
    • b2. Change import name as 'mysqlclient'

Now I prefer b1.


a is removed, see #232 (comment)

@adamchainz
Copy link
Contributor

I prefer option a, and option a2 with a release to tell people to use 'mysqldb'. This would help anyone stuck installing the old mysqldb, and reduce confusion between the two names.

@ushuz
Copy link

ushuz commented Dec 20, 2018

I prefer a1. This could save users some troubles.

Release packages for both name won't be a burden once the CI gets setup. As mysqlclient was once a drop-in replacement, it won't break anyone's code either. Users can continue to use the package name and imports they currently use, all they need to do is bumping version. It would feel like "it just work" to all users.

@methane
Copy link
Member Author

methane commented Dec 20, 2018

I prefer a1. This could save users some troubles.

A1 introduce troubles. If both of mysqlclient and MySQLdb are "proper" "maintained" "recommended" package, which should be used?
What happened if your project depends two packages "foo" which depends "MySQLdb", and "bar" which depends "mysqlclient"?

To avoid such confusion, we need one recommended name.

Additionally, I don't want to release same package to both name.
So a1 is the worst solution I think.

@ushuz
Copy link

ushuz commented Dec 25, 2018

@methane

The scenario you described will always happen, as those two names are already widely used. It can't be solved by any above means. Unless one name got entirely removed from PyPI, so everyone affected would be forced to switch to the "recommended" name, because they can't install through old name anymore, but this is definitely disastrous and won't worth the trouble.

a1 feels like this fork got merged back into https://github.com/farcepest/MySQLdb1. It helps mysqldb users, and it won't bother the users who currently use the name mysqlclient.

b2 is the worst IMO, it just creates more fractions, and should not be considered.
mysqldb / mysqlclient =====> mysqldb / mysqlclient (mysqldb) / mysqlclient (mysqlclient)

So my prefs:
a1 > b1, this is the status quo > a2, current mysqlclient user will have to change their code in future, as a mysqlclient user myself, I don't like being forced to change my code

@methane
Copy link
Member Author

methane commented Dec 25, 2018

The scenario you described will always happen, as those two names are already widely used. It can't be solved by any above means. Unless one name got entirely removed from PyPI, so everyone affected would be forced to switch to the "recommended" name, because they can't install through old name anymore, but this is definitely disastrous and won't worth the trouble.

It can be solved. MySQLdb become minor and minor. There are very few people installs MySQLdb newly by pip install. And even there are few people get stucked, they can find "mysqlclient is recommended", "MySQLdb is very outdated".

If MySQLdb resurrects, "which is recommended?" become confusing again.

Additionally, I don't want increase maintenance cost.
If no one maintain both of MySQLdb and mysqlclient, it must be worst situation.

it won't bother the users who currently use the name mysqlclient.

No. MySQLdb and mysqlclient conflicts. It can breaks their environment, if MySQLdb is added in their dependencies.

b2 is the worst IMO, it just creates more fractions, and should not be considered.
mysqldb / mysqlclient =====> mysqldb / mysqlclient (mysqldb) / mysqlclient (mysqlclient)

I agree that this option requires some efforts to all users.
On the other hand, this is requested by @zzzeek, and transition cost is not insane high.
For example, Pillow had supported both of import Image and from PIL import Image for long time.
They removed import Image at last. There were confusing, but it was not unacceptable.

I think this option should be considered. But I don't have motivation for this project to inform widely this transition.

@methane
Copy link
Member Author

methane commented Dec 25, 2018

After re-reading PEP 541, I think a is impossible.

  • Reachability: @farcepest is almost unreachable. But he response very rarely. So I'm not sure.
  • Abandoned projects: If he is considered unreachable, it's clear that MySQL-python is avandoned. There are no release and activity.
  • Continued maintenance of an abandoned project:
    "the candidate is able to demonstrate why a fork under a different name is not an acceptable workaround" -- I demonstrated "fork under a different name" is acceptable workaround. Many users switched from MySQL-python to mysqlclient already.

So I must not be able to take over MySQL-python.

@ushuz
Copy link

ushuz commented Dec 25, 2018

For example, Pillow had supported both of import Image and from PIL import Image for long time.
They removed import Image at last. There were confusing, but it was not unacceptable.

IMO, changing from PIL to from pillow is more comparable to what @zzzeek requested.

After re-reading PEP 541, I think a is impossible.

@methane If that's the case, I'm perfectly OK with b1. Maintaining status quo won't require extra effort from neither maintainers nor users. Plus, b1 is what pillow did, and they are doing well.

I guess something could be learned from pillow, like explicitly advertising as Pillow (PIL fork).

image

@methane
Copy link
Member Author

methane commented Dec 25, 2018

I just meant changing import path is not "unacceptable" or "should not be considered" option.

@zzzeek
Copy link

zzzeek commented Dec 25, 2018

hey there, just a check in from downstream land, all the things i complained about in #44 have not happened, @farcepest is as far as I can tell 100% not reachable for many years now and I think all my users use mysqlclient now. if the pypi overlords want to give you mysql-python, that would be fine too.

@methane
Copy link
Member Author

methane commented Jan 18, 2019

I decided to not change (b1).
Thanks for your response.

@methane methane closed this as completed Jan 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants