declare django as a dependencies

[deronnax]

We had several issues when upgrading django where we would then have error in the form of You must use the latest version of django-snowflake X.Y.z with Django X.Y.z (found django-snowflake A.B.C). occasioning runtime error on staging/preprod.
Why not declare django as a requirement, where the required django version would be expressed, so this can be avoid at dependency installation time?

[timgraham]

Hi Mathieu,

This question has come up before in other database backends that I work on. I don't think it's appropriate for database backends (django-snowflake in this case) to manage the installed version of Django. Say I'm using Django 4.2 and I run pip install django-snowflake. That would install the latest django-snowflake (5.0 currently) and if Django is present in django-snowflake's install_requires, it would also upgrade Django to 5.0.x. That's probably not want to the user wants because upgrading Django is usually a non-trivial process requiring other updates.

Instead I would pin a major dependency like Django in a requirements file (at least to something like 5.0.* if you don't want to pin the micro version number) as well as the corresponding django-snowflake==5.0.*. Would that work for you?

[deronnax]

hmmm, we eventually did this, but it's still a burden: one day one of our new developers (and not even just ours) will get hit by this as well. I see two solutions:

• make django-snowflake support several version of django at once, as do many libraries (e.g all maintained django version). But I guess you don't want to otherwise you would already do it
• move the check to setup.py. This way, at least the warning about incorrect version would raise at install time. WDYT? (I think it should work)

[timgraham]

Since Django's database backend API isn't subject to API stability like the rest of Django, I've found it easiest and cleanest to have a separate version of the backend to match each version of Django. This eliminates the maintenance burden of conditional code based on the Django version.

I'll think about whether it's appropriate to move the version check to setup.py. Presently, there's no requirement to install Django before this library, though I suppose the version check could be skipped if Django isn't already installed.

Is it a burden to use a requirements file to manage dependencies? Frankly, I think it's quite risky not to. Is your normal workflow to install the latest version of each Django library and hope everything works?

[deronnax]

We use PDM, it is like Poetry.
The requirements file would not solve the problem, the problem is that with the current working, the version non-matching between django and django snowflake is only caught in the late runtime, whereas it's something people expect to be caught at the packaging/dependencies definition step.

[timgraham]

I haven't used modern package management systems, so my thinking on this might be antiquated. It might be that including a Django version restriction in django-snowflake's install_requires is most beneficial, despite the scenario I described in my first comment.

[deronnax]

I confirm that PDM and Poetry do not reproduce pip's behavior quirk to uninstall existing django to accommodate django-snowflake requirements. So I think it's time to put the dependencies management old world to rest and embrace the new one :)

[deronnax]

thank you so much