search

etianen / django-watson

Full-text multi-table search application for Django. Easy to install and use, with good performance.
BSD 3-Clause "New" or "Revised" License
1.2k stars 129 forks source link

Installation conflict with other watsons #274

Open jayvdb opened 4 years ago

jayvdb commented 4 years ago

At least https://github.com/watsonpy/watson-framework and https://github.com/TailorDev/Watson also install as 'watson' into site-packages. The latter is PyPI td-watson and is already packaged by distros, at least openSUSE which I do packaging for.

https://pypi.org/project/Watson/ may also, but it looks like it might be abandonware.

c.f. https://github.com/barseghyanartur/django-nine/issues/2 for a similar issue, where a django package was renamed. If you are interested in going down that route, I would be happy to assist trying to make it as painless as possible.

In this case, django-watson was the 'first' by a few years, and it also has higher stats at https://pypistats.org/packages/django-watson than the other two, but those stats exclude distro installs. td-watson does have higher GitHub stars ;-) I'm just starting the conversation here, as this is the package I want to add to openSUSE and it has a conflict with an existing package. I'm open to all ideas, and dragging in the other maintainers as well to find the best solution.

jayvdb commented 4 years ago

If nothing else, it would be great if we can make this watson "relocatable" to django_watson. i.e. distros applying a patch to setup.py which installs it to a non-standard directory. Then as long as "django_watson" is put into INSTALLED_APPS, and relative imports are used, distro users should be able to use this without further adjustments. Not ideal, and that patch would be unsupported by the project team here, but it is a way forward.

etianen commented 4 years ago

There's an issue here, in that the "watson" namespace is used in database tables too. Anything that depends on "watson" will have to update not only their import statements, but also any raw SQL queries.

It's pretty unfortunate that PyPi lets this happen. But there's a precedent of django-related projects having a django- prefix in PyPi but installing the package without the prefix. And patching/renaming stuff is going to confuse people.

How about all the different "watson" packages are just marked as conflicting in the Debian package metadata? That's a pretty accurate representation of what's happening here. I have a feeling that most people use pip/virtualenv/pipenv to manage dependencies rather than the system package manager anyway.

jayvdb commented 4 years ago

There's an issue here, in that the "watson" namespace is used in database tables too.

Django now has a workaround for this with app "label"s. Usually this works. This would be part of the distro patching. The one type of Django naming which is unsolved afaik is route namespaces, but that only causes problems when two apps use the same namespace. We dont have two Django apps here, so I think we should be ok.

Agree re PyPI, very poor metadata historically, but getting better. And I am currently doing Conflicts: in the .spec, but wish to improve on that.

But there's a precedent of django-related projects having a django- prefix in PyPi but installing the package without the prefix.

Yup, agreed.

I have a feeling that most people use pip/virtualenv/pipenv to manage dependencies rather than the system package manager anyway.

Absolutely. And solving the system packaging problem should not be at the expense of those users, and doesnt need to be rushed.

And patching/renaming stuff is going to confuse people.

It is only going to impact people who use distro packages for their Django server, which is a very limited subset. But still I take your point, it isnt the best outcome, and arguably even Conflicts: may be better. Maybe one of the other packages can be renamed, either upstream or by patching, with less impact.

etianen commented 4 years ago

Interesting points. Thanks for looking into this so thoroughly.

I ultimatately don't mind if you make a distro-specific patch, and would be happy to tweak the django-watson codebase if the impact was small and it made your life easier. Non-django packages are probably easier to patch, but it sounds like you're considering everything quite sensibly.

Let me know what decision you come to, and if there's anything I can do to help out! :)