Installation conflict with other watsons about django-watson HOT 4 OPEN

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! :)

from django-watson.

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.

from django-watson.

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.

from django-watson.

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.

from django-watson.