Python 3 support

[nikolay]

$ jetstream
Traceback (most recent call last):
  File "/Users/nikolay/Projects/test/venv/bin/jetstream", line 7, in <module>
    from jetstream.cli import main
  File "/Users/nikolay/Projects/test/venv/lib/python3.6/site-packages/jetstream/cli.py", line 22, in <module>
    from jetstream import publisher, template, testing
  File "/Users/nikolay/Projects/test/venv/lib/python3.6/site-packages/jetstream/template.py", line 41
    raise RuntimeError, message, tb
                      ^
SyntaxError: invalid syntax

[nikolay]

Duh! You don't support Python 3. Any plans for that?

[jarosser06]

I honestly don't see why we can't support it we just haven't taken the time to do it. If I get a chance in the next couple of weeks I'll get it compatible assuming Troposphere is as well.

[stevengorrell]

Trying not to resurrect an old thread, but I don't really want to start a new one. The following message is now appearing during CircleCI tests:

DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.

It's not clear when pip will drop support but I can imagine it will be soon™ after 2.7 is EOL. I think we as a group need to look into getting Jetstream into the py36 realm as soon as possible.

[cwgem]

Given that Python 2.7 is EOL in almost a year from now it's time to take some more action on this. cloudtools/troposphere#1299 indicates that we can mostly utilize the 2to3.py method of install to handle a decent portion of the migration. From there will be doing the actual python 3-ization work. This mostly will be broken down to:

• Finding items where a solution exists for python 2 and 3 ( cmp -> == for example )
• Finding areas where there is only a python 3 equivalent
• Addition of CI tests considering the weight of the change

The work for both of these will mostly converge into a brute force method of running jetstream and seeing where errors occur under python 3. From there just keep iterating until it mostly works. Then from there testing a wide range of template generation to see if there are any edge cases.

All work will be done in a v2 branch of some kind to avoid issues with master suddenly changing and leaving python 2 / non-migrated users in the dust. Release will be tagged off the v2 branch and labelled as 2.0.x. The reason for jumping the version gap so much is that I believe jetstream for the most part has been in 1.0 territory for quite awhile, we just never had a solid release process to constitute this. Also having a v2 branch but the version naming being v1 would be rather confusing. From then on we can stick to a mostly SemVer method of versioning.

Once all work is done there should most likely be a 3 month or so grace period of v2 branch being the core area for Python 3 work. Once that period is over we can merge to master and have it as master from there. Given that we will be using tags from here on out, that should help lock people into certain points without having to worry too much about branch names.