Psycopg2 python 3 install mac os

prakashanantha / install-psycopg2

ruby -e «$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)»

brew install postgresql

sudo pip install psycopg2

This comment has been minimized.

Copy link Quote reply

yajing-wang commented Oct 24, 2019

This comment has been minimized.

Copy link Quote reply

mahesh122000 commented Nov 26, 2019

but asking password

This comment has been minimized.

Copy link Quote reply

sham-hq commented Mar 13, 2020 •

pip3 install psycopg2-binary
worked for me

This comment has been minimized.

Copy link Quote reply

liujiajun commented May 13, 2020

This comment has been minimized.

Copy link Quote reply

ruddhisundar commented May 19, 2020

Thank you, Sham-HQ! It also worked for me on my mac! Jaya SeeyaRaam!

This comment has been minimized.

Copy link Quote reply

KozlovDmitry commented Jul 24, 2020

pip3 install psycopg2-binary
worked for me

Thanks, it works for me too

This comment has been minimized.

Copy link Quote reply

niravlogistic commented Dec 3, 2020

pip3 install psycopg2-binary

worked for me also

This comment has been minimized.

Copy link Quote reply

abhinaypotti commented Mar 6, 2021

pip3 install psycopg2-binary
worked for me

Thank you.. Worked for me too

This comment has been minimized.

Copy link Quote reply

tinaty commented Apr 22, 2021

pip3 install psycopg2-binary
worked for me

thank you very much, this way worked for me too.

This comment has been minimized.

Copy link Quote reply

erickvilela commented May 2, 2021 •

Thank you, Sham-HQ! It also worked for me on my mac! Jaya SeeyaRaam!

Much easier than everything I’ve tried so far. For the virtualEnv, worked pretty fine! Thank you!

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Как установить psycopg2?

Несколько дней пытаюсь решить проблему — не получается.

UPD: решил с помощью команды

• Вопрос задан более трёх лет назад
• 18806 просмотров

Please add the directory containing pg_config to the PATH
or specify the full executable path with the option:

python setup.py build_ext —pg-config /path/to/pg_config build .

Вроде прямым текстом говорят — корректный путь к постгресу в PATH надо добавить. Либо указанным способом, либо

pip install psycopg2

Здравствуйте.
Лог ошибки читал, пытался пропатчить на что возвращалось

usage: sudo -h | -K | -k | -L | -V
usage: sudo -v [-AknS] [-g groupname|#gid] [-p prompt] [-u user name|#uid]
usage: sudo -l[l] [-AknS] [-g groupname|#gid] [-p prompt] [-U user name] [-u user name|#uid] [-g
groupname|#gid] [command]
usage: sudo [-AbEHknPS] [-C fd] [-g groupname|#gid] [-p prompt] [-u user name|#uid] [-g
groupname|#gid] [VAR=value] [-i|-s] []
usage: sudo -e [-AknS] [-C fd] [-g groupname|#gid] [-p prompt] [-u user name|#uid] file .

Пытался вставить -e, не получалось и забросил этот способ
С sudo не дружу ещё, недавно освоил bash

Источник

Psycopg 2.9.1 documentation

Psycopg is a PostgreSQL adapter for the Python programming language. It is a wrapper for the libpq, the official PostgreSQL client library.

Quick Install¶

For most operating systems, the quickest way to install Psycopg is using the wheel package available on PyPI:

This will install a pre-compiled binary version of the module which does not require the build or runtime prerequisites described below. Make sure to use an up-to-date version of pip (you can upgrade it using something like pip install -U pip ).

You may then import the psycopg2 package, as usual:

psycopg vs psycopg-binary¶

The psycopg2-binary package is meant for beginners to start playing with Python and PostgreSQL without the need to meet the build requirements.

If you are the maintainer of a published package depending on psycopg2 you shouldn’t use psycopg2-binary as a module dependency. For production use you are advised to use the source distribution.

The binary packages come with their own versions of a few C libraries, among which libpq and libssl , which will be used regardless of other libraries available on the client: upgrading the system libraries will not upgrade the libraries used by psycopg2 . Please build psycopg2 from source if you want to maintain binary upgradeability.

The psycopg2 wheel package comes packaged, among the others, with its own libssl binary. This may create conflicts with other extension modules binding with libssl as well, for instance with the Python ssl module: in some cases, under concurrency, the interaction between the two libraries may result in a segfault. In case of doubts you are advised to use a package built from source.

Change in binary packages between Psycopg 2.7 and 2.8¶

In version 2.7.x, pip install psycopg2 would have tried to install automatically the binary package of Psycopg. Because of concurrency problems binary packages have displayed, psycopg2-binary has become a separate package, and from 2.8 it has become the only way to install the binary package.

If you are using Psycopg 2.7 and you want to disable the use of wheel binary packages, relying on the system libraries available on your client, you can use the pip —no-binary option, e.g.:

which can be specified in your requirements.txt files too, e.g. use:

to use the last bugfix release of the psycopg2 2.7 package, specifying to always compile it from source. Of course in this case you will have to meet the build prerequisites .

Prerequisites¶

The current psycopg2 implementation supports:

• Python versions from 3.6 to 3.9
• PostgreSQL server versions from 7.4 to 13
• PostgreSQL client library version from 9.1

Build prerequisites¶

The build prerequisites are to be met in order to install Psycopg from source code, from a source distribution package, GitHub or from PyPI.

Psycopg is a C wrapper around the libpq PostgreSQL client library. To install it from sources you will need:

The Python header files. They are usually installed in a package such as python-dev or python3-dev. A message such as error: Python.h: No such file or directory is an indication that the Python headers are missing.

The libpq header files. They are usually installed in a package such as libpq-dev. If you get an error: libpq-fe.h: No such file or directory you are missing them.

The pg_config program: it is usually installed by the libpq-dev package but sometimes it is not in a PATH directory. Having it in the PATH greatly streamlines the installation, so try running pg_config —version : if it returns an error or an unexpected version number then locate the directory containing the pg_config shipped with the right libpq version (usually /usr/lib/postgresql/X.Y/bin/ ) and add it to the PATH :

You only need pg_config to compile psycopg2 , not for its regular usage.

Once everything is in place it’s just a matter of running the standard:

or, from the directory containing the source code:

Runtime requirements¶

Unless you compile psycopg2 as a static library, or you install it from a self-contained wheel package, it will need the libpq library at runtime (usually distributed in a libpq.so or libpq.dll file). psycopg2 relies on the host OS to find the library if the library is installed in a standard location there is usually no problem; if the library is in a non-standard location you will have to tell Psycopg how to find it, which is OS-dependent (for instance setting a suitable LD_LIBRARY_PATH on Linux).

The libpq header files used to compile psycopg2 should match the version of the library linked at runtime. If you get errors about missing or mismatching libraries when importing psycopg2 check (e.g. using ldd) if the module psycopg2/_psycopg.so is linked to the right libpq.so .

Whatever version of libpq psycopg2 is compiled with, it will be possible to connect to PostgreSQL servers of any supported version: just install the most recent libpq version or the most practical, without trying to match it to the version of the PostgreSQL server you will have to connect to.

Non-standard builds¶

If you have less standard requirements such as:

• creating a debug build ,
• using pg_config not in the PATH ,

then take a look at the setup.cfg file.

Some of the options available in setup.cfg are also available as command line arguments of the build_ext sub-command. For instance you can specify an alternate pg_config location using:

Use python setup.py build_ext —help to get a list of the options supported.

Creating a debug build¶

In case of problems, Psycopg can be configured to emit detailed debug messages, which can be very useful for diagnostics and to report a bug. In order to create a debug package:

• Download and unpack the Psycopg source package (the .tar.gz package).
• Edit the setup.cfg file adding the PSYCOPG_DEBUG flag to the define option.
• Compile and install the package.
• Set the PSYCOPG_DEBUG environment variable:

• Run your program (making sure that the psycopg2 package imported is the one you just compiled and not e.g. the system one): you will have a copious stream of informations printed on stderr.

Non-standard Python Implementation¶

The psycopg2 package is the current mature implementation of the adapter: it is a C extension and as such it is only compatible with CPython. If you want to use Psycopg on a different Python implementation (PyPy, Jython, IronPython) there is a couple of alternative:

• a Ctypes port, but it is not as mature as the C implementation yet and it is not as feature-complete;
• a CFFI port which is currently more used and reported more efficient on PyPy, but please be careful of its version numbers because they are not aligned to the official psycopg2 ones and some features may differ.

Running the test suite¶

Once psycopg2 is installed you can run the test suite to verify it is working correctly. From the source directory, you can run:

The tests run against a database called psycopg2_test on UNIX socket and the standard port. You can configure a different database to run the test by setting the environment variables:

• PSYCOPG2_TESTDB
• PSYCOPG2_TESTDB_HOST
• PSYCOPG2_TESTDB_PORT
• PSYCOPG2_TESTDB_USER

The database should already exist before running the tests.

If you still have problems¶

Try the following. In order:

• Read again the Build prerequisites .
• Read the FAQ .
• Google for psycopg2 your error message. Especially useful the week after the release of a new OS X version.
• Write to the Mailing List.
• If you think that you have discovered a bug, test failure or missing feature please raise a ticket in the bug tracker.
• Complain on your blog or on Twitter that psycopg2 is the worst package ever and about the quality time you have wasted figuring out the correct ARCHFLAGS . Especially useful from the Starbucks near you.

Источник

pip install of psycopg2 on Mac OS X El Capitan results in unusable build #385

Comments

cjw296 commented Dec 23, 2015

Please see this Stack Overflow question:

ArtHarg’s answer worked for me, and suggests it may be possible to fix this on the psycopg2 side.
Please let me know what I can do to help!

The text was updated successfully, but these errors were encountered:

dvarrazzo commented Dec 23, 2015

Duplicate of issue #378

Which I don’t know if it will be fixed or not, but you can just compile the lib statically.

cjw296 commented Dec 23, 2015

@dvarrazzo — I’m hoping you can re-open this issue if I phrase it in a different way. So, steps to reproduce:

• Install Postgres on Mac OS using the standard EnterpriseDB installer, 9.4 in my case
• Create a virtualenv using Python 2.10 and the latest virtualenv
• pip install psycopg2

Compilation, linking and installation will succeed with no errors, but attempting to import the resulting library will result in the error shown in the above Stack Overflow question:

As such a standard install of psycopg2 on a standard install of Mac OS X is currently non-functional. While experienced users can fight their way through, it’s not great for anyone else.

What could we do to improve things?

cjw296 commented Jan 2, 2017

@dvarrazzo — a year later, has any progress been made on this? I see you closed the bug you referred to as invalid, but the above is still a common use case for psyocpg2 users on a Mac.

dvarrazzo commented Jan 2, 2017

@cjw296 If any, it is a problem shared by any extension library on OSX. Do every Mac OSX user have the same issue or it is a matter of certain setups?

There is no progress being made on this issue: I don’t have Mac OSX to test with, nor any Mac specific expertise, and nobody who does has stepped in to help with that.

cjw296 commented Jan 10, 2017

Every Mac user of psycopg2 will have this problem, if they do a pip install psycopg and don’t use one of the documented hacks.

Interestingly, conda has a psycopg2 build that doesn’t exhibit these problems, probably for the reasons described here: http://conda.pydata.org/docs/building/shared-libraries.html#shared-libraries-in-linux-and-os-x

I see from https://pypi.python.org/pypi/cryptography/1.7.1 that Mac wheels are now built, I’m pretty sure that’s to deal this this issue. Maybe @reaperhulk or @alex could help with how they solved the problem there?

As far as Mac building goes, Travis supports Mac builds:
https://docs.travis-ci.com/user/multi-os/

cjw296 commented Jan 10, 2017

For the next time I need it:

dvarrazzo commented Jan 10, 2017

It seems the delocate tool is useful to create a package with a local copy of the depending libraries and to hack the binary to find them.

Would you be able to help me creating OSX wheel build for psycopg (issue #479)? I have a branch where I create the builds for linux (issue #425). I would like to extend it to OSX and Windows too, but it is likely that a separate project could be a better option.

This project seems to have everything requested to create the builds on Travis.

cjw296 commented Jan 12, 2017 •

I’m certainly interested, as with all these things, it’s finding time.

Not sure about delocate . Thinking more about it, you probably want to link to the libraries on the user’s system, otherwise you’re going to have to build wheels not only per python version and per platform, but also per postgres version that you want to support.

The key thing is to end up with an absolute path when linking, rather than a relative one. These Macs all have postgres installed, and pg_config is providing the correct information, it’s just that the resulting .so has a relative rather than an absolute path to libssl.1.0.0.dylib and friends, so when the OS tries to load it, it can’t find it.

dvarrazzo commented Jan 12, 2017 •

Linking to the system libraries is exactly the problem that the wheels try to solve and the reason you opened this bug. Python on OSX is not a simple thing, from what I’ve learned reading MacPython notes.

I don’t want to customise personally the build system on a platform I know little about. python setup.py build_ext should just work, and it does on most of the system, if the build prerequisites are met. If the built artifact has relative paths, not absolute, it’s a problem with your build tool, it doesn’t happen to others. I don’t know what install_name_tool is, and sure I can’t rely I will find it everywhere. Building the wheels solves your problem and the need to install the prerequisites (build tool matching python, the postgres client lib).

We don’t have to support different Postgres versions: libpq is backwards compatible, we would just package the latest available.

I’m certainly interested, as with all these things, it’s finding time.

That’s hard for everyone. I’ll take it as a no and will keep on working at my pace. This bug will be fixed by the release of the wheels.

reaperhulk commented Jan 13, 2017

If you want to statically link psycopg2 reliably on macOS there’s several things you need to be able to do:

• Not pass -lssl -lcrypto -lpq to the linker.
• Pass the absolute path to the static libs (this can be done via LDFLAGS )
• Since you’re now statically linking libpq you’ll need to add -framework Kerberos -framework LDAP so that those are dynamically linked against the system since libpq (if obtained from homebrew at least) will be compiled with GSSAPI and LDAP support.

I did a quick hack of the setup.py to let me do this on the mac (just stripping the linker args and then doing CFLAGS=»-I/usr/local/opt/openssl/include» LDFLAGS=»/usr/local/opt/openssl/lib/libcrypto.a /usr/local/opt/openssl/lib/libssl.a /usr/local/opt/postgresql/lib/libpq.a -framework Kerberos -framework LDAP» pip install -vvv . ) and this appears to work without issue.

There is some added complexity in deciding if the wheels should be built against the python.org Python releases as well as whether you want universal (aka x86 + x86_64 fat binaries) libs, but we can tackle that later.

I could potentially submit a PR that does all this via a travis job, but I’d love some guidance on whether adding flags to the configparser for build_ext is the right path here. There’s already a static_libpq , but that still attempts to build a path on the user’s behalf, whereas here we probably just want to be able to pass absolute paths as part of the build process to generate an artifact that most users will consume. Regardless, let me know what makes sense in the context of the project’s current layout!

cjw296 commented Jan 13, 2017

@reaperhulk — interesting, I do wonder if static linking is going to create more problems than it solves.

Reading what you’ve written, I wonder if something pg_config is setting in the environment is causing Python’s extension building process to go badly?

The snippet above looks like things that might be relevant.

reaperhulk commented Jan 13, 2017 •

@cjw296 static linking doesn’t really carry any drawbacks beyond the ones that are already present with bundling delocated dylibs. Depending on your pg_config output the extension building could definitely be problematic. In my environment I have postgresql from homebrew, which is linked against homebrew openssl, so if I just do pip install psycopg2 it actually installs and runs successfully.

Edit: Forgot to mention that it’s likely that some of the alternate Postgres installers on the mac bundle their own private libssl/libcrypto dylibs and that may be a contributing factor in the varying problems people have. Building a wheel with all the deps bundled (via static linking or local dylibs) will resolve that of course.

cjw296 commented Jan 13, 2017

. but psycopg2 doesn’t currently bundle delocated dylibs, and I’m not advocating for that any more than shipping statically linked wheels.

I use the EnterpriseDB provided Mac OS X installer, which looks like the official way to install postgres on Mac OS, as best I could tell. The pg_config output snippets above are from that.

So, back to my question: I wonder if something that pg_config is setting in the environment is causing Python’s extension building process to go badly? Could psycopg2 do something to encourage Python’s extension building process to ignore the bad bits?

dvarrazzo commented Jan 13, 2017

Thank you very much for the ongoing discussion. @reaperhulk, no, I don’t think adding flags to the configparser for build_ext is the right path: because as you say Python OSX is built with different toolkits and architecture a binary package should keep account of all of them: the MacPython wiki has more info. This result in chubby packages, catering for different architectures: just see the numpy wheels filename.

AFAICS the Travis OSX machines have all that is needed to build the aforementioned chubby packages. More specifically, I would only publish packages that are built on Travis: If it comes from there, it will go on PyPI.

I have just created the psycopg2-wheels project whom I would like to give the same structure of the numpy one. If things are the way I expect them to be, it would be best to move there the manylinux build I was writing instead in a psycopg2 branch. This way we can separate the travis builds: pushing into psycopg2 repos would run the test suite on the supported platforms. Pushing into psycopg2-wheels would happen at release time and would upload packages e.g. on initd.org, from where they can go on PyPI (or directly on PyPI, to be decided).

On a note related to this conversation: I would avoid psycopg static build, I’m not sure it still works ok. Again, if numpy guys use delocate I would use it as well. Pure unduly cargo-cult 🙂

Thank you for your interest in the feature, and contribution is very, very, welcome (possibly reporting that in bug #479).

dvarrazzo commented Feb 2, 2017

@cjw296 @reaperhulk There is now this project to build binary wheels on Travis CI: https://github.com/psycopg/psycopg2-wheels If you can contribute building wheels for OSX it would be great.

dvarrazzo commented Feb 11, 2017

I have uploaded some test OSX wheels package on testpypi. Could you please check if they work?

Thank you very much.

cjw296 commented Feb 12, 2017

doesn’t look like the wheel is being found:

cjw296 commented Feb 12, 2017

Ah, right, those wheels are only found with newer versions of pip. My pip was 7.0.1, updating to 9.0.1:

dggsax commented Jan 29, 2020

@cjw296 Well it’s 2020 and I was running into issues with psycopg2 installation again, using your solution, I was able to install it. It’s still unclear what sorts of things could cause this particularly library to have such an issue, but yeah hopefully this can help more folks.

dvarrazzo commented Jan 29, 2020

@dggsax your message doesn’t help if you don’t say:

• what problem you had
• how you solved it.

I doubt you have the same problem someone had 4 years ago, right?

dggsax commented Jan 29, 2020 •

@dvarrazzo Thanks for the tip, I should’ve considered that when making my first comment. I was indeed having a very similar problem that sparked this initial thread. Using Mac Catalina 10.15.1.

Problem
Created a virtual environment and attempted to install psycopg2 using pip3 install psycopg2 . The package installs fine with no issues or errors, but then as soon as I use sqlalchemy anywhere in my Flask project, I get the following error message.

Research on this thread as well as some others gave lots of different reasons and solutions that involved messing with symlinks and paths, but I found that the following solution worked best for me and solved my issues:

Solution

After doing this, my sqlalchemy worked without a hitch and resolved my issues and the methods in my Flask project that weren’t working before were then working.

dvarrazzo commented Jan 29, 2020

That sound to me like you installed psycopg 2.7.7, and you may get whatever broken testing package.

You are better off if you configure your dependencies (e.g. requirements.txt) with psycopg .

I don’t know who suggested you to install from testpypi, but that’s deranged.

dggsax commented Jan 29, 2020

I followed your suggestion and installed psycopg2-2.7.7 by running pip3 install pyscopg2==2.7.7 that fixed my initial problem. I’ve crossed out my initial solution since it’s not the recommended one as you said.

New Solution
Since I use homebrew to install and manage OpenSSL on my computer, this solution works for me. So, if you are a Mac user and you don’t have libssl.1.0.0 or greater in your /usr/lib directory, then this is the solution for you.
pip3 install pyscopg2==2.7.7

Thank you for the help and for helping me make sure my comments were more specific and helpful (and to also know that installing from testpypi is a bad idea)! @dvarrazzo Below is some more info about the issue between v2.7.7 and v2.8.4 in my case just in case you or someone else may be interested. Should I just make a new issue with specific error message and provide the concise solution there and close it for others to find?

More info related to the differences between v2.7.7 and v2.8.4

So what is the difference between psycopg2-2.7.7 and psycopg2-2.8.4 ?

I think I figured out where things were becoming an issue on my specific machine. After re-reading my initial error message and re-installing 2.8.4 (using pip3 install pyscopg2 ), I get the same error message from my previous comment again. Specifically, it looks like it’s trying to reference OpenSSL 1.0.0 based on this part of the message:

Library not loaded: /usr/local/opt/openssl/lib/libssl.1.0.0.dylib

That path does not exist on my machine. Instead, my machine has /usr/local/opt/openssl/lib/libssl.1.1.0.dylib whereas libssl1.0.0.dylib lives in /usr/local/opt/openssl@1.0/lib/libssl.1.0.0.dylib .

Curious about the differences between 2.7.7 and 2.8.4, I decided to figure out what versions of OpenSSL the compiled libraries required.

• With psycopg2-2.8.4 installed I ran, otool -L /env/lib/python3.7/site-packages/psycopg2/_psycopg.cpython-37m-darwin.so which had the following output:

• With psycopg2-2.7.7 installed, the same otool command had the following output:

So, version 2.7.7 seems to reference openssl-0.9.8 directly from /usr/lib which works fine on my machine because /usr/lib/libssl.0.9.8.dylib exists. Then version 2.8.4 expects openssl-1.0.0 at /usr/local/opt/openssl/lib/libssl1.0.0.dylib .

But, then based on your response in #1030 it looks like it’s not pyscopg2 requiring openssl but rather libpq as you mention. You also say that the library works with openssl-1.1.1, so I wonder if version 2.8.* is just incompatible with macs that use homebrew to install OpenSSL because of how homebrew installs packages now in /usr/local/opt . So, if I really, really wanted to use version 2.8.4, I would need to manually install openssl 1.0.0 or greater without homebrew.

Источник