Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update psycopg2 requirement to psycopg2-binary #5

Open
goetzb opened this issue Apr 8, 2019 · 0 comments
Open

Update psycopg2 requirement to psycopg2-binary #5

goetzb opened this issue Apr 8, 2019 · 0 comments

Comments

@goetzb
Copy link

goetzb commented Apr 8, 2019

When I made a deployment today, I've noticed that deployment failed due to a requirement in Django Postgres Stats. This failure is related to a recent change in the psycopg2 Python package.

Background

Until release 2.8, the psycopg2 package installed the binary package by default. However, this behaviour has now been changed and from release 2.8 on, there is a separate binary package available named psycopg2-binary which should be used instead (see also the "What's new in psycopg 2.8" section in https://github.com/psycopg/psycopg2/blob/master/NEWS or on http://initd.org/psycopg/articles/2019/04/04/psycopg-28-released/).

While this change has been communicated for a while, it only became a problem with the actual release of 2.8 on 4 Apr 2019.

Solution

Currently, the Django Postgres Stats requirements.txt (https://github.com/rtidatascience/django-postgres-stats/blob/master/requirements.txt#L2) lists psycopg2>=2.6.1 as dependency. Unfortunately, this version isn't available as psycopg2-binary package, the first release with the new name is 2.7.3.2 (see also https://pypi.org/project/psycopg2-binary/#history).

So, I would suggest to change that one line in the requirements.txt to:
psycopg2-binary>=2.7.3.2

While inconvenient to force an update of the psycopg2 package, given that 2.7.3.2 was released on 24 October 2017 (http://initd.org/psycopg/articles/2017/10/24/psycopg-2732-released/), the change should probably not be a big problem for most actively maintained applications.

Side note

For my own application, I could simply remove the dependency on django-postgres-stats entirely, since everything we currently use is supported by Django 2.0 natively (EXTRACT for DurationField was the last bit that was missing until 2.0, see also https://docs.djangoproject.com/en/2.1/ref/models/database-functions/#django.db.models.functions.Extract).

Kind regards,
Goetz

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant