Will Traitlets 5.0 ever be ? [Help wanted]

Sorry for the catchy title, but it’s mostly to catch your attention.

I recently had some time and was able to send a PR to traitlets – for those of you that dont’ know traitlets it’s basically the library the powers all of the Jupyter configuration System and some of (ipy)widgets synchronization.

Current traitlets stable is 4.3.x and the master branch (supposed to become 5.0) separated from 4.x several years ago. Traitlets master accumulated many Pull requests through the years with really good usability improvements, but life being what it is maintenance decreased and everybody started to be scared of releasing.

Up until a few weeks ago traitlets was not tested on Python versions greater than 3.6 to give you an idea.

So it felt like traitlet 5.0 was in Limbo.

I am now trying to see if we can get traitlets 5.0 out in a couple of weeks, but I need help.
I re-reviewed almost all of the PR that went into 5.x since a few years ago, still a couple I need to wrap my head around. But I need some help for codebase update.

This is your time to do an easy contributions !

  1. I do not think we need to keep compatibility with Python 2.7, and actually if we follow NEP29 we can also drop 3.6. I would gladly get some help to cleanup the codebase: you mission if you accept it is to find one file that uses six for example, or funcsig or have a conditional code path for an unsupported Python version. Help me remove that and make the code cleaner.

Please limit to one file at a time to not make the review too difficult and leave pieces for others !

Do you agree we can drop 2.7, 3.3, 3.4 and 3.5 ?
Are you Ok to drop 3.6 ?

  1. install master on your machine and report any problem.

  2. Look at some of the interesting PR with the 5.0 milestone, and write a short paragraph in the documentation that explain how it works., what is new, how to go from the old way to the new way of doing things.

  3. You know of a downstream project using traitlets ? Send them a Pull Request that test with traitlets master and report any failures to the traitlets repository.

With this I’m fairly convince by next month we can get a traitlets 5.0 beta out. and maybe traitlets 5.0 by end of July.

Thanks !

2 Likes

RHEL/CentOS 8 (which is the latest version) packages Python 3.6- that’s one argument in favour of keeping support.

Well but that’s going to be an argument for the next 5 to 10 years…
Do you think there will really be users of traitlets 5.x with system Python on Centos ?

Usage of the PEP-0487 __set_name__ hook should enable some cleanup of the metaclass magic which might make it more maintainable going forward.

For me, maintainability is crucial so I’d be inclined to stick to NEP-29.

My thinking was that use of a distribution packaged Python (dnf install python36) makes installation of applications such as JupyterHub a lot easier. FYI I’m currently running JupyterHub on CentOS 7. Obviously it’s possible to install other Python versions and I’ve done that before, but it’s an additional step for sysadmins. At some point RedHat/CentOS will release an official package for a more recent Python, as they did with CentOS 7, so it wouldn’t require indefinite support.

How would you like to see downstream projects that use traitlets change? Switch to 5.0 and drop 4.0 which means they also need to bump their supported Python versions? Or keep supporting 4.0 and therefore not take advantage of new changes in 5.0? In the latter case the change to Python 3.7 in traitlets is less of an issue.

Regarding the code update, have you looked at any automated tools? https://github.com/asottile/pyupgrade/ sounds like it might be helpful? (I haven’t tried it.)

Ha, I’m also running a JupyterHub on centos 7, but I went for a completely isolated anaconda install as a non-system user.

I see traitlets 5.0 a bit like a 4.4, it has just accumulated a lot of new functionality, and I just don’t want master to diverge too much. I’m fine keeping full compat with 4.0. It should still be the case. The only big change that I see would be dropping some old Python version support (mainly 2.x) , and some deprecation warnings. But basically I want to stop having to cherry-pick a coupleof new critical features here and there on the 4.x branch.

Yes I’ve seen pyupgrade, and I’m thinking about using pyupgrade + black + isort, but I don’t like large scale codebase reformat.

That is interesting. I’m probably not going to explicitly do this refactor, but it’s good to know.

1 Like