Open Stack

On Tue, Jun 11, 2013 at 2:54 AM, Julien Danjou <julien at danjou.info> wrote:

> On Tue, Jun 11 2013, Joe Gordon wrote:
>
> [ Following up on -dev ]
>
> > As many of you have probably seen, there has been a community effort to
> > begin the slow process to making OpenStack python 3 compatible. There is
> > even a weekly meeting discussion it (
> > http://eavesdrop.openstack.org/meetings/python3/2013/)
> >
> > As this is inherently a massive cross project effort, I was hoping the TC
> > would comment on the python 3 efforts.
> >
> > * What versions of python we want to compatible with
> > * Do we *want* all projects to by python 3 compatible or should we focus
> > our efforts on oslo and client libraries etc?
> > * Do we want to begin gating on some python 3 compatibility?
> >
> https://github.com/openstack-dev/hacking/commit/e0ab03637da65bfc6035091989b62fc70ae363a5
> > * etc.
>
> It kind of seems obvious to me that nobody in the TC is going to object
> to any effort bringing compatibility to Python 3. :-) I bless that and
> would love to help going into this direction actually.
>
> All project should go to Python 3 at some point, but it seems logical to
> start by every dependency like Oslo, and as discussed during the Python
> 3 session at the summit, starting with client libraries is going to be
> easier than porting whole projects. We're probably years from that
> concerning projects like Nova for example.
> Considering this timeframe, targetting latest Python 3 releases is going
> to be largely good enough.
>

The etherpad from that summit session that Eric led is
https://etherpad.openstack.org/havana-python3

As Julien said, we agreed to start with clients and dependencies first. The
reliance on eventlet may make it difficult to port the existing servers,
and there is a lot of other code to work on, so we decided to wait and see
what happens with async libraries under Python 3 and start with the "easy"
stuff. It is also more likely that a client will want Python 3 support than
that a server will require it.

We're targeting at least Python 3.3, with the idea that we'll be able to
use Tulip. That minimum version may change based on what's current at the
time the work makes enough progress for us to talk about settling on a
version. I can't imaging it going lower, though.


>
> And concerning gating, I can't see any objection as long as everything
> is automatized.
>


For testing we said we would set up a separate tox stanza for with the test
runner configured to run only the subset of tests for modules expected to
work with Python 3. That way in oslo-incubator, for example, we don't have
to port everything at once, we can just run a subset of the tests and
prevent regressions after we get a module working with 3. That does imply
that we want gating jobs for Python 3.3 for projects where the work has
reached a point that it makes sense to start enforcing compatibility.

By the way, Chuck Short has been doing a lot of really good work on Python
3 compatibility already, but I'm sure he would appreciate some help.

Doug


>
> --
> Julien Danjou
> # Free Software hacker # freelance consultant
> # http://julien.danjou.info
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130611/a6d5527d/attachment.html>