-
Notifications
You must be signed in to change notification settings - Fork 42
Clash with zacharyvoase/slugify #42
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
Comments
Answer: you will get whichever got installed last. I"m not sure what anyone can do about this -- there is no authority for who gets to use what names for packages (except for standard library packages). |
NOTE: the project at: https://github.com/zacharyvoase/slugify hasn't been updated for 11 years. Des it even work with Python 3.6+ ? This one is 5 years old, but still newer than that one. So I'd hope no one is using the much older one. Also -- Are the APIs different? maybe it doesn't matter? |
It also conflicts with https://github.com/un33k/python-slugify, which is still actively updated. To my knowledge, the only solution is to install the packages in separate virtual environments. |
"To my knowledge, the only solution is to install the packages in separate virtual environments." well, yes, but if you have a dependency on both, you are stuck :-) Anyway, as you say, python-slugify is being actively maintained, I haven't tried it out yet, but I"ll probably simply use that instead. |
The project at https://github.com/zacharyvoase/slugify named "slugify" also has the module name "slugify".
If you add both packages to your requirements.txt, what happens when you import "slugify"?
The text was updated successfully, but these errors were encountered: