Unnecessary psycopg dependency

[gavinwahl]

Why does this project specify a psycopg dependency? I'd like to manage that requirement myself rather than by installing this project.

[codingjoe]

Hi there 👋,

Thank you for reaching out. That's an excellent question. I know that I used to be common to exclude major dependencies like Django from Django's 3rd party packages. However, if your package imports any behavior for another package, you should maintain a proper dependency. That includes setting minimum versions. For example, your package only supports Django 4.2 and above? You should include that in your dependencies, description.

In our case, this package does require psycopg (2 or 3) and in specific version, based on your Django version. We mirrored, that mainly for your CI setup. We should move the test setup, but realistically, this package implements a PostgreSQL feature; thus you will always need client bindings. Officially, Django supports only psycopg.

However, I am curious, what issues did you run into? We are always open to improving this package, since it's an important fallback option, since the CITEXT removal from Django contrib.

Best,
Joe

[gavinwahl]

1. My code has a dependency on psycopg2, so installing django-citext broke it and I had to troubleshoot that. Django automatically uses psycopg3 instead of 2 when 3 is installed.
2. The psycopg2 install of django-citext also installs psycopg 3 so my project is still broken.

    $ pip install 'django-citext[psycopg2]'
    ...
    Installing collected packages: typing-extensions, sqlparse, psycopg2-binary, asgiref, psycopg, django, django-citext
    Successfully installed asgiref-3.8.1 django-5.1 django-citext-1.0.2 psycopg-3.2.1 psycopg2-binary-2.9.9 sqlparse-0.5.1 typing-extensions-4.12.2
    

3. An extension project shouldn't require me to do this troubleshooting in the first place.

[marcelofern]

Good morning @codingjoe

From the commit history, the dependency has been added to satisfy the CI workflow added on 53e5177. The CI workflow could, instead, have it's own dependency file so that projects using this library don't need to have a new dependency added to their projects.

a new dependency added to their projects.

This is because there are other ways to satisfy psycopg requirements. For example, one can use psycopg-binary instead.

I'd recommend removing the psycopg or adding explicit installation paths for those other supported libs as well. Up to you, of course (-:

[codingjoe]

Hello again. The binary dependencies can still be installed, by adding psycopg[binary] to your dependencies. This is also the method that is recommended by the psycopg community. We can document this somewhere, but you shouldn't (in theory) have any issues by default. I am using the binary dependency on my projects myself without any collisions. As for dropping it, I would prefer to keep it, especially if we have any version conflicts that my come up in the future. Cheers Joe