Quite a bit of time has passed since the last release of flashbake. I had some time to myself yesterday during my week off while my visting family was out of the house with the kids. I decided to act on a couple of pull requests and tag those along with some file layout changes as a new release.
Version 0.27 is also the second release that I’ve uploaded to pypi, the Python package index from which flashbake can easily be installed with setuptools. I used this request from a user to do some reading on git. The first release I pushed to pypi, as a test, was the previous one, 0.26.3. I created a short lived maintenance branch to add the additional metadata that pypi submission requires. That change has been merged into the main branch for the project hence this new release also being pushed to pypi.
You can see the release notes for this and all past releases on github. The source distribution is available from github as well. If you are familiar with installing python packages using easy_install, you can now do so with flashbake. I am not sure how long it will take for MacPorts and Debian to pick up this change.
The next release will probably be a while coming. Hopefully the reason will not be lack of activity but rather the ambition of its scope. I have used the git Python library, a wrapper that works more directly wirh git’s internals, for another project with good success. I plan to rip out as much of my own git specific code in favor of using this existing library and where that doesn’t cover to change the process interaction code to take advantage of git’s porcelain option that produces machine readable output.
The reason for overhauling the git code, including introducing a plugin protocol for other VCS’s, is so that I can finally tackle remote operations in git. I’ve now been bitten a couple of times by forgetting to push changes on my work machine in projects where I am dog fooding flashbake. Eventually we will be getting a VPN but for now this breaks my own writing workflow pretty badly. Clearly if flashbake could smartly push local changes where there is a remote origin configured for the repo, that would be the correct fix.
If you have any thoughts on remote operation support, in particular any odd use cases for me to consider other than a sole author working rather naively, let me know and I’ll try to factor it into my design and implementation.