qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: Python 3 port is 'done'
Date Thu, 30 Apr 2015 15:08:11 GMT


----- Original Message -----
> From: "Ken Giusti" <kgiusti@redhat.com>
> To: proton@qpid.apache.org
> Cc: users@qpid.apache.org
> Sent: Thursday, April 30, 2015 9:18:26 AM
> Subject: Re: Python 3 port is 'done'
> 
> 
> 
> ----- Original Message -----
> > From: "Rafael Schloming" <rhs@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 <kgiusti@redhat.com> wrote:
> > 
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Rafael Schloming" <rhs@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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message