On Sun, Mar 16, 2014 at 8:47 AM, Fraser Adams <[email protected] > wrote:
> On 16/03/14 10:21, Rafael Schloming wrote: > >> >> and >>>> >>>>> Scanning dependencies of target docs-py >>>>> +----------------------------------------------------------- >>>>> --------------- >>>>> | In /home/fadams/qpid/qpid-trunk/proton/proton-c/bindings/python/ >>>>> | proton.py: >>>>> | Import failed (but source code parsing was successful). >>>>> | Error: NameError: name 'PN_CONNECTION_STATE' is not defined (line >>>>> | 3292) >>>>> | >>>>> >>>>> >>>>> It looks like your new API docs are created OK, but I've raised >>>>> PROTON-535 >>>>> to cover it. >>>>> >>>>> Did you do a make prior to doing make docs or just do make docs? The >>>>> >>>> epydoc >>>> generation imports the swig modules so it needs the C code to be built >>>> in >>>> order to run in its entirety, however it falls back to source only mode >>>> if >>>> the import fails. >>>> >>>> --Rafael >>>> >>>> I've just done >>>> >>> make clean >>> make >>> make docs >>> >>> and it does the same thing. >>> >> >> That's interesting. I'm definitely not seeing that issue. What happens >> when >> you run python and type 'import proton' manually? Is it possible your >> PYTHONPATH and/or LD_LIBRARY_PATH are pointing you to an older version or >> something? Your epydoc version might also shed some light on the problem. >> I'm on 3.0.1. >> >> --Rafael >> >> So this is weird: > > bringing up a terminal and in my home directory > > running python and then doing "import proton" directly into the python > shell doesn't give any errors. > > > > Changing directory to > > <proton>/examples/messenger/py > > I can also happily run the send.py, recv.py, send_async.py, recv_async.py > messenger examples with no errors by doing. > ./recv.py > etc. and also > python recv.py > > and in that directory running python and then doing "import proton" > directly into the python shell doesn't give any errors either. > > > > > However, changing directory to > > <proton>/proton-c/bindings/python > > Then running python and then doing "import proton" directly into the > python shell I see: > > >>> import proton > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "proton.py", line 3292, in <module> > class Event: > File "proton.py", line 3294, in Event > CONNECTION_STATE = PN_CONNECTION_STATE > > NameError: name 'PN_CONNECTION_STATE' is not defined > > > > Hmmmm, I wonder. I've previously done a "make install" which was a little > while ago using a 0.6 Proton, I did that to build Qpid with AMQP 1.0 > support, but I've not done it for a little while (I think that there are > currently some incompatibilities with 0.7 so I've held off). At a guess the > reason that I can just run ./recv.py in <proton>/examples/messenger/py and > why import proton can actually see proton there and in my home directory is > due to the *installed* version. But calling import python in > <proton>/proton-c/bindings/python will see the version in that directory > in preference to the installed version? > > So I'm wondering if there's perhaps an issue with proton.py on trunk?? > So my guess is that when you cd into the bindings directory and import from there you are ending up with a mix of the trunk python code importing your older swigged module from its installed location, and looking for a constant that wasn't defined in 0.6, but is now there in 0.7. The safe way to work with trunk builds and ensure that you're not picking up anything from local installs is to source the config.sh file that is in the root of your source checkout. This shell script will set up your LD_LIBRARY_PATH, your PYTHONPATH, etc so that you are always picking up stuff from the source checkout. Note that the shell script assumes you either use an in-tree build or a build directory named "build" if you do something different you will need to set the CPROTON_BUILD environment variable before sourcing config.sh. --Rafael
