This project is archived and is in readonly mode.
Cannot build without pg_config
Reported by Steven Winfield | May 21st, 2012 @ 01:05 PM
I'm trying to build psycopg2-2.4.5 on windows (a 32-bit build on a 64-bit system, with MSVC, but that doesn't matter).
I have built the postgres client libraries (v9.1.3), which doesn't require Perl and for which there is an MSVC makefile, but this doesn't build pg_config.
In setup.cfg it says:
# If "pg_config" is not available, "include_dirs" can be used to locate
# postgresql headers and libraries. Some extra checks on sys.platform will
# still be done in setup.py.
However, setting include_dirs (and library_dirs) does not remove the requirement to have pg_config on the PATH. I think that either this comment should be removed, as it conflicts with the instructions here ("The pg_config must be available in your path, or alternatively you must specify its full path in the setup.cfg file."), or setup.py should be modified to only use the PostgresConfig object if include_dirs and library_dirs are not set (preferable :-)).
Here's my custom setup.cfg:
[build_ext]
define=PSYCOPG_EXTENSIONS,PSYCOPG_NEW_BOOLEAN,HAVE_PQFREEMEM
use_pydatetime=1
have_ssl=0
pg_config=some_random_name
include_dirs=Z:\Path\To\My\Headers
library_dirs=Z:\Path\To\My\Libraries
(obviously I used real paths for the last two) ...and here's the output of "python setup.py install":
...
running build_ext
Error: pg_config executable not found.
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 ...
or with the pg_config option in 'setup.cfg'.
Comments and changes to this ticket
-
Daniele Varrazzo May 21st, 2012 @ 01:26 PM
- State changed from “new” to “open”
I'll see if I can drop the pg_config requirement in case the library paths have been specified. If you can provide patches I'd be appreciated, thanks.
-
Steven Winfield May 21st, 2012 @ 07:01 PM
Here's a patch.
pg_config was also being invoked to find the pg version number, so I've added another config option for a user to specify this along with include_dirs and library_dirs - if they don't then we fall back to 7.4.0 as before.
-
Daniele Varrazzo May 22nd, 2012 @ 12:25 AM
- State changed from “open” to “hold”
This patch is definitely not going to work with Python 2.4, the minimum version we support (string.format).
Apart from that it is exactly what I thought it would have been: a deep nesting of ifs. And there is the need of another information provided for the user. Looking at it, I am against this patch: it make the setup much worse to support an use case I see no reason for: if you have built libpq you can build pg_config as well, can't you?
If you think yours is a compelling case, please raise the issue to the mailing list and see if Federico approves it. For me it is steps behind to when the setup.py was really messy, and that's because we tried to support every possible setup combination - and I don't want to go back there.
-
Federico Di Gregorio May 22nd, 2012 @ 08:28 AM
I agree with Daniele. The old setup that didn't use pg_config was a mess of ifs, even if the number of versions it had to cope with was way smaller. My line here is that if you want to build everything from scratch vs using prebuilt packages then you should cope with tools pg_config and build them too if required.
-
Steven Winfield May 22nd, 2012 @ 08:29 AM
Fair enough.
String.format could easily be changed to use %, and the user only needs to provide pgversion if they really want to, but I take on board your wider point.
Perhaps the comments in setup.cfg should be changed, then, to be more consistent with the website?
-
Daniele Varrazzo May 22nd, 2012 @ 02:55 PM
Definitely we should sort out the inconsistency. Fog, shall we remove the *_dirs from setup.cfg?
-
Federico Di Gregorio May 22nd, 2012 @ 03:58 PM
Yes, we should remove it before next release and replace it with an explanation text.
-
Daniele Varrazzo May 22nd, 2012 @ 04:32 PM
- State changed from “hold” to “open”
Ok with something like that?
diff --git a/setup.cfg b/setup.cfg index db4e771..ce17624 100644 --- a/setup.cfg +++ b/setup.cfg @@ -22,26 +22,11 @@ have_ssl=0 # Statically link against the postgresql client library. #static_libpq=1 -# "pg_config" is the preferred method to locate PostgreSQL headers and -# libraries needed to build psycopg2. If pg_config is not in the path or -# is installed under a different name uncomment the following option and -# set it to the pg_config full path. +# "pg_config" is required to locate PostgreSQL headers and libraries needed to +# build psycopg2. If pg_config is not in the path or is installed under a +# different name uncomment the following option and set it to the pg_config +# full path. #pg_config= -# If "pg_config" is not available, "include_dirs" can be used to locate -# postgresql headers and libraries. Some extra checks on sys.platform will -# still be done in setup.py. -# The next line is the default as used on psycopg author Debian laptop: -#include_dirs=/usr/include/postgresql:/usr/include/postgresql/server - -# Uncomment next line on Mandrake 10.x (and comment previous ones): -#include_dirs=/usr/include/pgsql/8.0:/usr/include/pgsql/8.0/server - -# Uncomment next line on SUSE 9.3 (and comment previous ones): -#include_dirs=/usr/include/pgsql:/usr/include/pgsql/server - -# If postgresql is installed somewhere weird (i.e., not in your runtime library -# path like /usr/lib), just add the right path in "library_dirs" and any extra -# libraries required to link in "libraries". -#library_dirs= +# Add here eventual extra libreries required to link the module. #libraries= -
-
Daniele Varrazzo May 23rd, 2012 @ 10:10 AM
- State changed from “open” to “resolved”
Committed in my devel.
Thank you Steven, sorry for asking you a patch that we ended up not merging.
-
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
<b>WARNING:</b> the informations in this tracker are archived. Please submit new tickets or comments to <a href="https://github.com/psycopg/psycopg2/issues">the new tracker</a>.
<br/>
Psycopg is the most used PostgreSQL adapter for the Python programming language. At the core it fully implements the Python DB API 2.0 specifications. Several extensions allow access to many of the features offered by PostgreSQL.
Daniele Varrazzo
Federico Di Gregorio
Steven Winfield