Test against Jupyterhub 0.9

[mbmilligan]

Jupyterhub 0.9 is available as a beta release now. We should make sure we test against it explicitly.

Note that 0.9 updates dependency versions to python >= 3.5 and tornado >= 5.

Full changelog here: https://jupyterhub.readthedocs.io/en/latest/changelog.html

If there are new features we want to add that are enabled by 0.9, please put those in separate feature request tickets.

[rkdarst]

How old do you want to still support? Right now there are 4x4 different tests:

python:
    - 3.6
    - 3.5
    - 3.4
    - 3.3
env:
    - JHUB_VER=0.5.0                                                                                                                                                          
    - JHUB_VER=0.6.1                                                                                                                                                          
    - JHUB_VER=0.7.2                                                                                                                                                          
    - JHUB_VER=0.8.1                                                                                                                                                          

Which of the old configs do you consider obsolete now? I would suggest limiting the matrix, and then implicitly including a few of the older version combinations. e.g. 7.2+ and 3.5+ and then 3.3/3.4 with older versions.

[willingc]

I would drop 3.3 and 3.4, and add 3.7. I am also inclined to drop all but JHub 0.8.1 @rkdarst Do you wish to create a PR to address?

[rkdarst]

I tend to think that HPC is rather conservative and slow to upgrade, so my inclination is to support backwards compatibility a lot. But, JupyterHub is changing so fast it probably doesn't make sense to use anything older than 0.8.1 anyway.

Thoughts?

[willingc]

@rkdarst Good point about the conservative cycle in HPC. I agree about backwards compatibility. Honestly, I was looking at this more from the maintainer perspective than the end user. My bad.

For Python, it makes sense, especially due to asyncio, to test on 3.5 and higher. 3.3 is already past end of life and 3.4 nearing it and in security only fixes. https://devguide.python.org/

For JupyterHub, it’s less clear to me. Folks do use older version 0.6, 0.7. I will defer to you, @minrk, and @mbmilligan on whether to test these.

[rkdarst]

Thanks. Thinking about it, one of my ideas was to limit the matrix and then add in just a few of the older python3.3/3.4 + one older jupyterhub. That probably handles enough of the older use cases.

The future pain will come from the new .progress method... will have to take special handling on python<=3.4, because since it's the async/await syntax, we can't just count on the method not being called. If it wasn't for that, I'd have no hesitation in continuing support for older versions. Do I remember some way to do this using another module?

[willingc]

@rkdarst Sounds like a good plan to add an older combo to the matrix. Go for it 👍

[willingc]

I suppose that you could check for the Python version and display progress differently for 3.4 and less. Not sure the performance impact.

[rkdarst]

What I meant was: progress requires `async` and `await` syntax which will fail at import time on python<=3.4. But, it seems the answer is `@asyncio.coroutine`/`yield from`, is that correct? (I knew there should have been some way to do this, I just didn't know what it was offhand). If this is the right way to do it, then no problem. The async_generator package is python3.5+ only, but we can just not do progress on python<3.4.

[mbmilligan]

Hi @rkdarst - thanks for all the work you're putting into this! Now that I'm back in the office, looks like I have a few threads to respond to. Apologies if I wind up covering some points twice or missing something.

The core issue here is what versions to support. In terms of Jupyterhub, we currently go back to 0.5, which is pretty old. 0.6 and 0.7 are inter-compatible with I think no changes needed in Batchspawner. However, 0.8 introduced breaking changes, so I could see some time passing before some of our users move past 0.7. (Mea culpa: we were running 0.3 until fairly recently in the production deployment here!) Thus, my inclination would be to support/test against the 0.7, 0.8, and 0.9 branches at least through our next release.

For Python, I would look to the distros. For users still on RHEL 6 (or CentOS equivalent, which is pretty common in HPC) or Debian Jessie (the current oldstable), it looks like Python 3.4 is the newest that is easily installable. I would be surprised if any HPC centers are running production 3.7 environments yet.

Thus, my proposal for the testing matrix would be Jupyterhub 0.[789] and Python 3.[456], excluding 3.4/0.9 since that can't ever work, and with added tests for Py 3.7 + Jupyterhub 0.9, and the current allow_failures test against master.

I'll comment on the .progress issue in the corresponding thread. But I suspect "don't do progress bars on older Python" will wind up being the answer, unless we discover a way to shim it in with backwards compatibility.