Not sure about psycopg2-wheels dependency

Hello, I’m psycopg2 maintainer.

I have developed wheel package of psycopg as a way to make tools like yours easier to install, but unfortunately the psycopg2 wheels has complex problems hard or impossible to eliminate, which forced us, in order to not get rid altogether of the wheel, to deploy them under a different pip name, as you have found seeing the requirements in your setup.py.

In psycopg/psycopg2#674 someone has reported though that the dependencies of pgcli cause problems to shared virtual envs. My suggestion would be to not have pgcli installed in the share virtualenv of other projects as it’s a standalone executable, not a library. However I’m not sure about that. The existence of a -wheel package is a new strategy for us so I’d like to find the best way to tackle the problem.

Do you think there are scenarios where pgcli is meant to be installed as a Python library for other projects? If so how can we solve conflicts where other projects depend on the naked psycopg2? Glad to know your opinion.

[bersace]

@dvarrazzo how do you manage a OR dependency with setuptools ? Something like psycopg2 | psycopg2-binary ? How to let user choose whether they use binary or build from source ?

[Zebradil]

I didn’t get it. Why we can’t just do the following?

diff --git a/setup.py b/setup.py
index 13c76c02..f4f11921 100644
--- a/setup.py
+++ b/setup.py
@@ -16,7 +16,7 @@ install_requirements = [
     'click >= 4.1',
     'Pygments >= 2.0',  # Pygments has to be Capitalcased. WTF?
     'prompt_toolkit>=2.0.6,<2.1.0',
-    'psycopg2 >= 2.7.4,<2.8',
+    'psycopg2 >= 2.7.4',
     'sqlparse >=0.2.2,<0.3.0',
     'configobj >= 5.0.6',
     'humanize >= 0.5.1',

I haven’t noticed any problems with the latest psycopg2 so far.