Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

Cannot build without pg_config

#109

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

Reported by Steven Winfield · May 21st, 2012 @ 01:05 PM

State: resolved
Milestone: none
Assigned to: nobody

Activity

  1. Daniele Varrazzo
    Daniele Varrazzo
    • 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.

    May 21st, 2012 @ 01:26 PM

  2. Steven Winfield
    Steven Winfield

    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.

    May 21st, 2012 @ 07:01 PM

  3. Daniele Varrazzo
    Daniele Varrazzo
    • 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.

    May 22nd, 2012 @ 12:25 AM

  4. Federico Di Gregorio
    Federico Di Gregorio

    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.

    May 22nd, 2012 @ 08:28 AM

  5. Steven Winfield
    Steven Winfield

    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?

    May 22nd, 2012 @ 08:29 AM

  6. Daniele Varrazzo
    Daniele Varrazzo

    Definitely we should sort out the inconsistency. Fog, shall we remove the *_dirs from setup.cfg?

    May 22nd, 2012 @ 02:55 PM

  7. Federico Di Gregorio
    Federico Di Gregorio

    Yes, we should remove it before next release and replace it with an explanation text.

    May 22nd, 2012 @ 03:58 PM

  8. Daniele Varrazzo
    Daniele Varrazzo
    • 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=
    

    May 22nd, 2012 @ 04:32 PM

  9. Federico Di Gregorio
  10. Daniele Varrazzo
    Daniele Varrazzo
    • 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.

    May 23rd, 2012 @ 10:10 AM

  11. Steven Winfield
    Steven Winfield

    No problem :-)
    Thanks for fixing setup.cfg

    May 23rd, 2012 @ 10:12 AM