Check earlier for django compatibility

[rafiss]

Relaying feedback that I received from one of our customers:

App devs have run into problems during upgrade of django-cockroachdb. The plugins dependencies do not seem to limit usage of the old version of django. For example you can recreate by:

1. Use Pipenv to set up django project
2. Freeze django to version 4.x.x
3. Run pipenv
4. See that the lockfile in django_cockroachdb is 5.0.0
5. App crashes

I believe the crash is happening due to the runtime version check in https://github.com/cockroachdb/django-cockroachdb/blob/ef465e1fa63a5045a450877b4bdd5e9931fa9e9a/django_cockroachdb/utils.py#L6

Can we check earlier for this mixed configuration? Perhaps with something like install_requires=[“django>=4.0.0<5.0.0”]?

[timgraham]

I'll have to try these steps to understand the issue a little better, however, I believe the question of whether or not to put Django in install_requires came up years ago. At that time, I didn't think it was appropriate because it's not django-cockroachdb's job to manage the installed version of Django but the developers job to select the correct version of django-cockroachdb. Say I am using Django 4.2 and I run pip install django-cockroachdb. That would install the latest django-cockroachdb (5.0 currently) and if Django is present in django-cockroachdb's install_requires, it would also upgrade Django to 5.0.x. That's unlikely to be what the user wants. Now maybe using pipenv changes things and would give an error in that case if Django is "frozen" to 4.2.x? I haven't used it so I'm not sure.

[stevewilliamsuk]

Thanks for your feedback @timgraham

The issue that I have is that when the new version of Django comes out, the django_cockroachdb driver isn't necessarily released the same day.

When pip/poetry/pipenv runs it's analysis, it sees the version 5.x.x of Django and may well elect to install that (unless I freeze it to 4.x.x), and because the django_cockroachdb driver 4.x.x does not predicate that it will only work with 4.x.x pip will keep the latest 4.x.x cockroach driver but use the latest 5.x.x django

We then have to deliberately freeze-down django to 4.x.x as a result (if we don't our apps wont start up when they are deployed), after a couple of days when django_cockroachdb is released pip then keeps django 4.x.x and updates django_cockroachdb to 5.x.x which means we lose the time cycles again.

I suppose the workaround for us is that when we freeze django, we also freeze django_cockroachdb

Hopefully you catch my drift?

[timgraham]

I would certainly freeze a major dependency like Django (at least something like 5.0.* if you don't want to pin the micro version number) as well as the corresponding django-cockroachdb==5.0.*. In the large projects I've worked on, upgrading to the next major version of Django usually requires non-trivial testing and changes for backward-incompatible changes in Django. As you said, often third-party Django apps aren't immediately compatible with new versions of Django either, however, they may not necessarily specify a maximum version of Django in install_requires. I wouldn't rely on a pip/poetry/pipenv analysis to determine what version of Django is safe to use.

[timgraham]

This complaint was also made on another backend that I maintain. With modern package management tools, it appears that the benefit of adding Django to install_requires may outweigh the drawback I articulated, so I'm going to do it starting with django-cockroachdb 5.1.