Python3 Strategy

[JamesGuthrie]

I am working on a port of pyretic to python3 for my own needs. Things are looking good so far, I am just wondering what your approach to supporting py2 and py3 is.

I guess there's not much demand yet from pyretic users for py3 compatibility, so having py2 support may be a desired feature. It would probably be too much maintenance effort to develop simultaneously on py2 and py3 branches. I would suggest there are a two options to maintaining py2 and py3:

• One codebase which is py2 and py3 compatible (using something like six)
• Move forwards with master py3-only, tag current release as py2 and move forward with py3, backporting important changes if necessary.

The porting that I have done for myself does not support py2 and py3 compatibility, but it would probably be possible to make it work. Py3 is not going anywhere and py2 will not progress past 2.7.x, so developing for py3 on master sort of matches current python development.

My question is: is there any reason why moving forward with the master branch being py3 and having a py2 tag for "backwards compatibility" is a terrible idea? If so, it might be worth investing the effort in having a single py2 and py3 compatible codebase, otherwise I would prepare a pull request with the python3 changes.

[joshreich]

We’ve discussed moving to py3 a couple of times in the past, but most of the world was still running on py2. Also, other components which Pyretic uses, particularly pox and mininet, are py2.

With respect to the first, taking a look around, it seems like things are slowly changing---e.g., Ubuntu has made progress on making py3 their standard https://wiki.ubuntu.com/Python. With respect to the second, from a quick glance, it appears that running both py3 and py2 on the same machine is not as difficult as it once was.

So, I think it would be reasonable to move to py3, though at the same time, I don’t see a pressing need to do so. So it should really be about what the community wants. Other folks, please jump in w/o your thoughts.

-Josh

From: James Guthrie [mailto:[email protected]]
Sent: Tuesday, May 26, 2015 4:51 AM
To: frenetic-lang/pyretic
Subject: [pyretic] Python3 Strategy (#47)

I am working on a port of pyretic to python3 for my own needs. Things are looking good so far, I am just wondering what your approach to supporting py2 and py3 is.

I guess there's not much demand yet from pyretic users for py3 compatibility, so having py2 support may be a desired feature. It would probably be too much maintenance effort to develop simultaneously on py2 and py3 branches. I would suggest there are a two options to maintaining py2 and py3:

• One codebase which is py2 and py3 compatible (using something like sixhttps://pypi.python.org/pypi/six)
• Move forwards with master py3-only, tag current release as py2 and move forward with py3, backporting important changes if necessary.

The porting that I have done for myself does not support py2 and py3 compatibility, but it would probably be possible to make it work. Py3 is not going anywhere and py2 will not progress past 2.7.x, so developing for py3 on master sort of matches current python development.

My question is: is there any reason why moving forward with the master branch being py3 and having a py2 tag for "backwards compatibility" is a terrible idea? If so, it might be worth investing the effort in having a single py2 and py3 compatible codebase, otherwise I would prepare a pull request with the python3 changes.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47.

[JamesGuthrie]

Thanks for the response Josh.

With regards to the dependencies:

• pox does not need to be on the same python version as it is run as a separate process anyway. The code which invokes pox needs to be properly decoupled, which I have opened a PR for as part of Ryu backend integration #44. Additionally the IPC needs to be cleaned up for py3, which I have done in my own branch.
• mininet is still on py2, but it looks as though the include dependencies are not in the pyretic core itself, but in the tests and evaluations directories.
• ryu is still on py2 (pyretic uses their packet library) but they are currently actively working on py3 compatibility.

I am not pushing for others to port pyretic to py3. Rather, I am wondering if a port is undertaken what the community would like to have, how many are tied to py2-only pyretic.