On 30/04/15 11:08 -0400, Ken Giusti wrote:
----- 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?
I'd probably have cmake/ctest running things for the default python and leave the rest of the tests to `tox` as it'll create the required virtual environments for each supported version. This would be my preference. That said, you could also have cmake building the bindings for each version in different paths. This will complicate the cmake step further and I presonally think this belongs to the bindings, Cheers, Flavio
> > --Rafael > -- -K-- -K
-- @flaper87 Flavio Percoco
pgphggkRH5Opl.pgp
Description: PGP signature
