Bug 31653 - cario.version_info seems to be reporting wrong value
cario.version_info seems to be reporting wrong value
Status: RESOLVED FIXED
Product: pycairo
Classification: Unclassified
Component: general
unspecified
x86-64 (AMD64) Linux (All)
: medium normal
Assigned To: Steve Chaplin
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-16 00:19 UTC by Adam Compton
Modified: 2011-01-22 18:02 UTC (History)
0 users

See Also:


Attachments
setup.py - line switch patch (324 bytes, patch)
2011-01-22 13:38 UTC, swoon
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Compton 2010-11-16 00:19:19 UTC
I apologize in advance if this is excessive; I'm trying to provide all relevant information ahead of time, rather than making you guys have to ask me questions.

I'm running Gentoo Linux on AMD64, with both "cairo" and "pycairo" at 1.8.10.

When attempting to use pycairo functions from wxPython, I get the following error:


adam@adamc: $ ./cairotest.py
Traceback (most recent call last):
  File "./cairotest.py", line 26, in OnPaint
    cr = wx.lib.wxcairo.ContextFromDC(dc)
  File "/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/lib/wxcairo.py", line 121, in ContextFromDC
    ctx = pycairoAPI.Context_FromContext(ctxptr, pycairoAPI.Context_Type, None)
AttributeError: 'Pycairo_CAPI' object has no attribute 'Context_FromContext'


I did some digging, and it looks like the _fields_ value in wxcairo.py there isn't getting populated because pycairo's version_info string is reporting (1, 10, 8) instead of (1, 8, 10). Here's the pdb output that led me to that conclusion:


AttributeError: 'Pycairo_CAPI' object has no attribute 'Context_FromContext'
> /usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/lib/wxcairo.py(121)ContextFromDC()
    120         # Turn it into a pycairo context object
--> 121         ctx = pycairoAPI.Context_FromContext(ctxptr, pycairoAPI.Context_Type, None)
    122

ipdb> cairo.version
'1.8.10'
ipdb> cairo.version_info
(1, 10, 8)
ipdb>


I dug into the autoconf script that builds pycairo on my system, and it looks like the information is getting into the correct fields. Here's some of <build>/src/config.h:


/* Define to the full name and version of this package. */
#define PACKAGE_STRING "pycairo 1.8.10"

/* Define to the one symbol short name of this package. */
#define PACKAGE_TARNAME "pycairo"

/* Define to the version of this package. */
#define PACKAGE_VERSION "1.8.10"

/* pycairo major version */
#define PYCAIRO_VERSION_MAJOR 1

/* pycairo macro version */
#define PYCAIRO_VERSION_MICRO 10

/* pycairo minor version */
#define PYCAIRO_VERSION_MINOR 8

/* Define to 1 if you have the ANSI C header files. */
#define STDC_HEADERS 1

/* Version number of package */
#define VERSION "1.8.10"


Unfortunately, I don't know Python well enough to dig any further. It looks like the values are being added in the right order in <build>/src/cairomodule.c, so I don't know why I get them in the wrong order out of the compiled, installed library.

If I change wxcairo.py to look for "cairo.version_info < (1,11)" (instead of 1,9 like it is now), then everything seems to work fine. That's the workaround I'm going to use, but hopefully this report will be useful.

Thanks,
Adam
Comment 1 Steve Chaplin 2010-11-20 22:42:46 UTC
I cannot see where the problem is coming from - the config.h values you reported look correct. You could try uninstalling pycairo and reinstalling it from the source and seeing if the problem reoccurs.

Be aware there are 2 versions of pycairo
py2cairo for Python 2.x
pycairo for Python 3.x
Comment 2 swoon 2011-01-22 13:38:06 UTC
Created attachment 42318 [details] [review]
setup.py - line switch patch

This patch simply moves PYCAIRO_VERSION_MICRO a line lower, which fixes the fault cairo.version_info.
Comment 3 swoon 2011-01-22 13:47:38 UTC
Forgot to mention, the patch applies to the py2cairo repository. (Gentoo seems to have only an ebuild for the Python2 version.)
Comment 4 Steve Chaplin 2011-01-22 18:02:26 UTC
Thanks for the patch. Its been applied to the git repository.