…ycopg2-binary version
sqlalchemy-postgres-copy currently requires psycopg2. However, triage
requires psycopg2-binary, (and pip doesn't know that these provide the
same package). As such, a build of triage attempts to install BOTH
psycopg2 AND psycopg2-binary. Assuming this builds, it doesn't
necessarily provide the wrong version: -binary might overshadow
non-binary. However, not all test environments have the necessary
libraries to build psycopg2 from source; (hence, the need for a binary
version).
This change resolves the issue by requiring an UNMERGED version of
sqlalchemy-postgres-copy which requires psycopg2-binary.
---
However, this isn't ideal. Alternatives for future work include:
* replacing sqlalchemy-posgres-copy with our code -- (we scarcely get
any use out of the library, so we could just bring in what little we need)
* our own fork of sqlalchemy-postgres-copy
* producing a shim distro (or github repo) which installs an empty/no-op
psycopg2 -- to satisfy the requirement of sqlalchemy-postgres-copy (and
any others) -- while the actual module (import) is nonetheless satisfied
by our requirement of psycopg2-binary
* simply requiring psycopg2 (non-binary) in triage by changing the
requirement to: ``psycopg2==2.8.2``. This is the recommended version, and
which should no longer trigger warnings, as it will not allow installation
of the binary version at all. However, it will thus require that all users
of triage have postgresql libraries installed, or the build (and tox) will
fail with an error, e.g.:
You need to install postgresql-server-dev-X.Y for building a server-side
extension or libpq-dev for building a client-side application
---
Other options (which I don't think are workable):
* change the triage pip requirement to something like
``psycopg2==2.7.7 --only-binary psycopg2``, (or ``--no-binary``).
HOWEVER, this syntax is only supported by pip, not by setup.py installs,
(and thus it is not appropriate for triage).