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.
A bunch of notes about Paramiko, Fabric and Invoke, such as their websites, their Python 3 support, and more! With copious exclamation points!
Most open source projects store documentation in the source repo itself. This is easy to do, allows the doc builder to reference in-code documentation (like Python docstrings), makes contributions from others simpler, etc.
However, it doesn’t always play nice with “meta” information such as how to contribute, project roadmap, and so forth.
Life has continued to conspire against me, but this particular Friday I successfully wrested some time from other responsibilities and put out a couple of releases.
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.
In my previous blog post I mentioned that I intend to begin a regimen of smaller, more frequent releases in my open source projects. Afterwards, I started thinking more about what this meant and how software release schedules work in general. This is the result.
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.