----- Original Message ----- > From: "Ken Giusti" <kgiu...@redhat.com> > To: proton@qpid.apache.org > Cc: us...@qpid.apache.org > Sent: Thursday, April 30, 2015 9:18:26 AM > Subject: Re: Python 3 port is 'done' > > > > ----- Original Message ----- > > From: "Rafael Schloming" <r...@alum.mit.edu> > > To: proton@qpid.apache.org > > Sent: Thursday, April 30, 2015 9:00:14 AM > > Subject: Re: Python 3 port is 'done' > > > > On Thu, Apr 30, 2015 at 8:35 AM, Ken Giusti <kgiu...@redhat.com> wrote: > > > > > > > > > > > ----- Original Message ----- > > > > From: "Rafael Schloming" <r...@alum.mit.edu> > > > > To: proton@qpid.apache.org > > > > Sent: Wednesday, April 29, 2015 4:24:09 PM > > > > Subject: Re: Python 3 port is 'done' > > > > > > > > What happens when I run make test and I have both python2 and python3 > > > > installed on my system? Do the tests run once under each version or > > > > does > > > > one of the versions 'win'? > > > > > > At this point it only runs on the 'default' version - whatever > > > /usr/bin/python resolves to. > > > > > > I like the idea of having it run on all installed python versions, but I > > > haven't explored how to do that yet. > > > > > > I've been using virtualenv [1] to switch between the two versions of > > > python I have installed on my development station. Tox [2] is probably > > > the > > > best approach to enable testing against multiple python environments. > > > > > > I'll look into tox a bit and see what I can come up with. > > > > > > > My system comes with both python and python3 on my path. Just running > > python3 manually on proton/tests/proton-test will run it with the python3 > > interpreter. I don't know how standard this setup is (I'm running stock > > fedora 20), but it would be pretty easy to do a check in cmake and run the > > tests using python3 if present. > > > > I'm also a fan of running both python versions if present, but I also don't > > want to double the time it takes to run through the tests. Given that we > > are mostly looking for syntactic incompatibilities in the wrapper code > > here, I wonder if it would be sufficient to run a subset of the tests that > > is likely to give us good coverage on the wrapper code but doesn't bother > > trying to exercise all the C code twice. Obviously if this proves > > insufficient we could expand the subset. > > Oh yeah - totally agreed. Just some smaller subset of python-test would make > me happy. I found most problems were covered by the engine, codec, > transport test modules btw. If that's all we need, then simply running > python3 directly on the unit tests makes the most sense. >
Ah, turns out the 'hard problem' is not running the tests, but building both py2 and py3 binaries from the c-wrapper. Totally different include and link libraries and different install paths. Cmake doesn't appear to directly support this - it only resolves to one instance of python, though that instance can be configured. But nowhere does it provide a list of available pythons - we'd have to script that ourselves. Once we have that list, we should use the setup.py script to build/install the language specific module. setup.py already handles swig, so simply invoking setup.py for each available python interpreter would do all the heavy lifting. thoughts? > > > > --Rafael > > > > -- > -K > -- -K
