This project is archived and is in readonly mode.

mx erroneously detected inside virtualenv

#53

Briefly, the issue is that when installing psycopg2 in a virtualenv that was created with --no-site-packages (in an attempt to be completely independent of the underlying system), psycopg2's setup.py will still find mx and set HAVE_MXDATETIME=1. The compilation and install succeed, but since mx isn't installed in the virtualenv, importing psycopg2 results in an ImportError: can't import mx.DateTime module.

As far as I can tell, this happens because setup.py does

mxincludedir = os.path.join(get_python_inc(plat_specific=1), "mx")

to determine whether mx is available. That will find the mx include directory (eg, /usr/include/python2.6/mx) and it will be able to compile. But this is circumventing the virtualenv and isn't safe behavior when installing into a virtualenv.

I can easily set mxincludedir to a bogus directory to trick it into thinking mx isn't installed anywhere and get it to work, but that doesn't strike me as the best and cleanest solution.

I'm not sure exactly what the best solution is overall, but I'd suggest that one way or another, psycopg2 should only compile in mx.DateTime support when it can both find the mx headers and know that the mx python library will be available.

Reported by Anders Pearson · April 27th, 2011 @ 04:16 PM

State: resolved
Milestone: none
Assigned to: nobody

Activity

  1. Daniele Varrazzo
    Daniele Varrazzo
    • State changed from new to open
    • Tag set to build, mx, virtualenv

    Checking for the importability of mx at build time seems a good solution.

    May 3rd, 2011 @ 11:44 PM

  2. Daniele Varrazzo
    Daniele Varrazzo
    • State changed from open to resolved

    Fixed in my devel.

    May 4th, 2011 @ 12:18 AM

  3. Daniele Varrazzo
    Daniele Varrazzo

    I have committed a better fix, to be released soon. mx is now an optional dependency even when the support is built: at runtime, if not found, mx is disabled and psycopg can be imported anyway, only using stdlib datetime objects.

    June 4th, 2011 @ 11:45 PM