-
Notifications
You must be signed in to change notification settings - Fork 159
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
psycopg2-binary dependency #631
Comments
as I understand it, if we were writing an extension for psycopg this would be true. however, we repeat its parts, we do not expand the functionality, do not overlap the logic... psycopg-binary is fine in this case for task. |
I must have miss-interpreted it. Here is a direct quote:
|
You did not. It is against the advice of the psycopg2 developer to depend on the -binary package. |
+1 for replacing Helpful links:
Just to highlight the main issue with psycopg2-binary, please let me quote the author:
|
Any progress on this issue? It's becoming a problem for us as aiopg versions below 1.0.0 spam our consoles with hundreds of deprecation warnings, while upgrading brings in this clearly incorrect dependency. |
We moved to asyncpg. |
Note that the only actual problem with psycopg2-binary is that psycopg2 has some Very Wrong code in it to explicitly disable thread-safety in openssl. This doesn't cause a problem if you're building from source, because both psycopg2 and the stdlib end up using the same shared copy of openssl, and the stdlib fixes up the thread-safety thing. If you're using the pre-built psycopg2 wheel, though, it includes its own private copy of openssl, and no-one fixes the thread safety after psycopg2 messes it up. However! The whole mess with openssl thread-safety only applies to openssl 1.0.2 and earlier. In modern versions of openssl, openssl is always thread-safe, and the APIs that psycopg2 is misusing are no-ops. And openssl 1.0.2 was EOL a year ago. All supported versions of openssl are fine. (Also, I'm not sure aiopg even uses threads anyway?) So these days, there's literally no problem at all with the psycopg2-binary wheels, except that the psycopg2 maintainers insist on giving them a different name from the main release, which creates this situation where projects like aiopg are trapped between two bad options – if aiopg depends on psycopg2-binary, it breaks alpine, but if it depends on psycopg2, then it makes the experience substantially worse for everyone on windows/macos/every other linux distro. So you might want to pressure psycopg2 to fix this. |
Options:
How about: |
Big news, pscyopg2 moved on to psycopg3 and it should be a drop-in replacement. Then, I guess aiopg could require the lonely This is similar to what @nicktimko suggested but surfacing the fact that psycopg3 would be used under the hood to the user, instead of exposing and documenting the same extras dependencies in aiopg. |
I was just wondering if psycopg2-binary is the correct dependency. Their documentation recommends that it should not be used in production: http://initd.org/psycopg/docs/install.html#binary-install-from-pypi
The text was updated successfully, but these errors were encountered: