Long story short: I’m finally starting to drop Python 2 (and a few slightly older Python 3s) from my projects, in a phased manner. Background and details follow.

Some quick thoughts based on recent Twitter conversations about Python version support in OSS projects, presented in (ironically, given the topic) lazy bullet list format.

Changelogs are a frequently overlooked aspect of software release management. I’m going to outline the different approaches to keeping them, and describe a dumb yak shave I undertook to improve the situation for my own projects.

I run a handful of related open source projects, and two of them are merging. Specifically: the Python ‘ssh’ library is merging with Paramiko, of which it was a public fork. The bulk of the work for this merger is already done, and new releases of Paramiko and Fabric (the high level library which has over time used both Paramiko and ‘ssh’) will be out soon.

Implied by the above: I am now the maintainer of Paramiko! Huge thanks to Robey Pointer for creating it & maintaining the project for nearly a decade. I can only hope folks are still using software I wrote ten years out.

On what?

Vendorizing. Including dependencies inside your own source tree as if they were part of your application. Also known as ‘bundling’, ‘omnibus’ etc. I’m going to be talking about Python software specifically, but it’s a general problem.

I’m weighing the pros and cons of vendorizing vs relying on externally-installed libraries, as I don’t see a strong consensus on the topic – and am curious what others with different experiences and use cases have to say.