Not sure about psycopg2-wheels dependency

[dvarrazzo]

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.

[j-bennet]

pgcli's primary purpose is to be an interactive tool, not a library. We worked on extracting shared functionality into libraries such as pgspecial and cli_helpers. However, many users install pgcli and mycli into venvs, to avoid changes to their system-wide packages. I wish we could specify psycopg2 as either binary or source distribution, to be controlled with pip install flags, but I'm not sure if there's an existing way to do that.

@dbcli/pgcli-core @dbcli/mycli-core What do you think?

(Related issue: #844.)

[dvarrazzo]

If your userbase is already used to installing psycopg from source is maybe better to specify the dependency on the source package. Here is how to do it in a requirements.txt file but I'm not sure it works in setup.py too.

[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 ?

[bastianh]

This is a bit annoying .. I install pgcli into a django docker container that runs in aws to use it as the "manage.py dbshell" program so I don't need to install the postgres client itself.

Now, both.. psycopg2 and psycopg-binary get installed .. but it looks like it still prefers the non-binary version so I now get the warning also for the django and celery processes that also run in the container.

[brianbruggeman]

@dvarrazzo I think the irritation on my side is that every time I run a cli command, I actually have the warning pop up. It's not limited to just pgcli, but that is the primary use-case I do have. So I probably see this warning more than a few dozen times in a day. It gets old after the first 3 on the first day... it's to the point now that I want to patch psycopg2 every time its installed. In the future, please consider handling something like this in a different way (perhaps just as a documentation notice).

[j-bennet]

@brianbruggeman we suppressed this warning in pgcli a version or two ago. Do you keep seeing it?

[brianbruggeman]

@j-bennet I do.

* pgcli==1.10.3
 - psycopg2 [required: >=2.7.4,<2.8, installed: 2.7.5 (dt dec pq3 ext lo64)]

We instruct our developers to run pip install -e .[all] for our projects, which completely sets up an environment for development. For one of our projects, that also includes pgcli because it's super useful. However, pip ends up installing both psycopg2 and psycopg2-binary. In my development environment, I end up manually uninstalling psycopg2 and psycopg2-binary, and then installing psycopg2-binary. As a consequence, I see this line every time I run a command-line interface (our CLIs are extensively used for database access along with S3, EC2, etc.). I see it every time I run a pytest invocation, etc. So pretty much my every day is impacted by this:

UserWarning: The psycopg2 wheel package will be renamed from release 2.8...

[meeuw]

I think your hitting the limits of pip install -e ., when the packages have conflicting requirements you can workaround this by patching setup.py of the packages. You can do this by forking pgcli on pypi.

[zaro]

I have a Flask project where we use the psycopg2 driver and we simply use psycopg2-binary, it works well enough for our case and makes life simpler. But if I want to install pgcli , now everywhere I start seeing :

 UserWarning: The psycopg2 wheel package will be renamed from release 2.8; in order to keep installing from binary please use "pip install psycopg2-binary" instead. For details see: <http://initd.org/psycopg/docs/install.html#binary-install-from-pypi>.

And this is very annoying.

[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.