Support Python 3

[mr-c]

From common-workflow-language/common-workflow-language#65

[jmchilton]

I really need this for planemo, I claim it supports Python 3 but now cwltool is going to be a non-optional dependency.

[samuell]

I'm sure you guys know this, but I didn't until recently, so leaving this link to this python 2/3 compatibility library here for anyone looking at this.

[mr-c]

@jmchilton You aren't hiding cwltool behind an extra?

[jmchilton]

@mr-c - I am - https://github.com/galaxyproject/planemo/blob/master/setup.py#L104.

[serverhorror]

I'd love to see cwltool in this list: https://python3statement.github.io/

[mr-c]

@tetron Thoughts on python3statement/python3statement.github.io#77
(no particular timeline as we make no claims for ongoing support of any given release at this time)

[jmchilton]

2020 is going to come very quickly - I'd really appreciate it if this project did not to commit to dropping Python 2 support by that time.

[mr-c]

@jmchilton Care to elaborate? Does the Galaxy Project have a timeline?

[jmchilton]

@mr-c We don't even have a timeline for support of Python 3 let alone dropping Python 2. I suspect we will support Python 3 this year - it will probably be a major hackathon project next month and @nsoranzo is on a mission. It was almost three years after Python dropped support for Python 2.6 before we dropped support - so I would guess Galaxy will support Python 2.7 into 2022 - but timelines that far out seem silly.

I understand both that it would be easier to maintain exclusively Python 3+ code and that it makes a powerful statement to drop Python 2 support, I'm just letting you know there are projects that have this project as a dependency that I strongly suspect will no longer be able to use the latest and greatest version if you drop support for Python 2.7 in 2020.

[takluyver]

Are there any particular sticking points for supporting Python 3? I've helped update several codebases, and I'm happy to offer advice.

I had a quick go at cloning the repo and running the tests, but the test setup doesn't work out of the box even on Python 2.7, so I guess I'm missing something.

[mr-c]

@takluyver How are you running the tests? make test is how we do it (or via tox)

[mr-c]

@takluyver current discussions are ongoing at #310

[takluyver]

The README says python setup.py test, so that's what I tried. make test gives me a similar result, though. Here's what happens when I do that: https://gist.github.com/takluyver/08fb5894286470c5b156f3f5835eb1fd

[manu-chroma]

Hey @takluyver, I'm responsible for porting the codebase to Python 3.x as part of my GSoC project. Before porting cwltool, I'm in process of porting schema_salad which is a dependency of cwltool.

You can find my current WIP branch here and the checklist I prepared here.
Let me know your thoughts on my progress so far.

As for running the tests, you can simply invoke them using tox. 😄

[takluyver]

OK, the tests passed when I ran them with tox.

Your branch & checklist look pretty sensible to me.

Most projects I know of don't use from __future__ import unicode_literals, because there are some strings that do need to be the native str type on both Python versions, and wrapping them in str('foo') looks quite ugly. If the code is unicode-aware in Python 2, any strings for which it matters should already be u'unicode literals', and no change is required for Python 3.

[manu-chroma]

Thanks for your feedback. Yes, the codebase already had all the required strings marked using unicode() and when I ran modernize fixer, they got replaced by six.text_type().

[manu-chroma]

closing this one. refer to: #310