<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 2, 2014 at 11:17 PM, Clark Boylan <span dir="ltr"><<a href="mailto:cboylan@sapwetik.org" target="_blank">cboylan@sapwetik.org</a>></span> wrote:<br>
</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">
On Tue, Sep 2, 2014, at 11:30 AM, Yuriy Taraday wrote:<br>
> Hello.<br>
><br>
> Currently for alpha releases of oslo libraries we generate either<br>
> universal<br>
> or Python 2.x-only wheels. This presents a problem: we can't adopt alpha<br>
> releases in projects where Python 3.x is supported and verified in the<br>
> gate. I've ran into this in change request [1] generated after<br>
> global-requirements change [2]. There we have oslotest library that can't<br>
> be built as a universal wheel because of different requirements (mox vs<br>
> mox3 as I understand is the main difference). Because of that py33 job in<br>
> [1] failed and we can't bump oslotest version in requirements.<br>
><br>
> I propose to change infra scripts that generate and upload wheels to<br>
> create<br>
> py3 wheels as well as py2 wheels for projects that support Python 3.x (we<br>
> can use setup.cfg classifiers to find that out) but don't support<br>
> universal<br>
> wheels. What do you think about that?<br>
><br>
> [1] <a href="https://review.openstack.org/117940" target="_blank">https://review.openstack.org/117940</a><br>
> [2] <a href="https://review.openstack.org/115643" target="_blank">https://review.openstack.org/115643</a><br>
><br>
> --<br>
><br>
> Kind regards, Yuriy.<br>
</div></div>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
We may find that we will need to have py3k wheels in addition to the<br>
existing wheels at some point, but I don't think this use case requires<br>
it. If oslo.test needs to support python2 and python3 it should use mox3<br>
in both cases which claims to support python2.6, 2.7 and 3.2. Then you<br>
can ship a universal wheel. This should solve the immediate problem.<br></blockquote><div><br></div><div>Yes, I think, it's the way to go with oslotest specifically. Created a change request for this: <a href="https://review.openstack.org/118551">https://review.openstack.org/118551</a></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It has been pointed out to me that one case where it won't be so easy is<br>
oslo.messaging and its use of eventlet under python2. Messaging will<br>
almost certainly need python 2 and python 3 wheels to be separate. I<br>
think we should continue to use universal wheels where possible and only<br>
build python2 and python3 wheels in the special cases where necessary.<br></blockquote><div><br></div><div>We can make eventlet an optional dependency of oslo.messaging (through setuptools' extras). In fact I don't quite understand the need for eventlet as direct dependency there since we can just write code that uses threading library and it'll get monkeypatched if consumer app wants to use eventlet.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The setup.cfg classifiers should be able to do that for us, though PBR<br>
may need updating?</blockquote><div><br></div><div>I don't think so - it loads all classifiers from setup.cfg, they should be available through some distutils machinery.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
We will also need to learn to upload potentially >1<br>
wheel in our wheel jobs. That bit is likely straight foward. The last<br>
thing that we need to make sure we do is that we have some testing in<br>
place for the special wheels. We currently have the requirements<br>
integration test which runs under python2 checking that we can actually<br>
install all the things together. This ends up exercising our wheels and<br>
checking that they actually work. We don't have a python3 equivalent for<br>
that job. It may be better to work out some explicit checking of the<br>
wheels we produce that applies to both versions of python. I am not<br>
quite sure how we should approach that yet.<br></blockquote></div><div class="gmail_extra"><br></div>I guess we can just repeat that check with Python 3.x. If I see it right, all we need is to repeat loop in pbr/tools/integration.sh with different Python version. The problem might occur that we'll be running this test with Python 3.4 that is default on trusty but all our unittests jobs run on 3.3 instead. May be we should drop 3.3 already?<br clear="all">
<div><br></div>-- <br><br><div>Kind regards, Yuriy.</div>
</div></div>