A while back, I opened (as in ‘made available’) BitSyncHub, a tool to automatically synchronize Bitbucket repositories to Github. At the time I saw no real reason to open source it - it was a quick hack to solve my own problems, and I felt that anyone else could just reproduce it if they wanted to.
Since then, a whole lot of open source projects, including a few big names, has started using the service, and when I had to reply to a recent support request from one of these projects that I did not have time to look into their issue due to daytime work, I realized that some projects are now depending on the service staying up and working.
Since I got several requests for BitSyncHub to support BitBucket Git repository synching to GitHub, I went ahead and added the functionality. The service will dedtect the appropriate repository type, and push specified branches - although the source branch will be ignored for now, so a branch speficiation of ‘foo:bar’ will simply push ‘bar’.
To make this happen, I finally had to bring gitapi a bit closer to completion, so I released the first version to PyPi for general consumption as well.
Introducing BitSyncHub Since I’m an automation nut, when I found Travis CI, I was understandably excited - automatic running of my testcases for hgapi from the repository as opposed to a pre-push hook (as I have had it set up since the beginning of time) would avoid the oh-so embarrassing mistakes of forgetting to add a new file to the repository and having a non-working version in the repo. I just have to set up some service to synch to the GitHub mirror and all will.
I got a feature request on hgapi the other day, pointing out that it was not possible to filter the Mercurial log using the API, since there is no dedicated way to do it and the fallback method - sending keyword arguments that will be passed to the command line - does not work. The signature of the method in question is
def hg_log(self, identifier=None, limit=None, template=None, branch=None, **kwargs): with kwargs accepting any keyword arguments and passing them to the command line.
My name is Fredrik, and sometimes I write code I’m not that proud of.
A friend of mine started on a Python project recently, and when I asked him to put it up on Bitbucket his response was an immediate and not-quite-mock “But then people will see my code!”. I believe this fear of showing one’s code is common, and I believe that it is a problem. Not so much for open source, or anything like that, but for the individual - it suggests a belief that your code isn’t good enough, that other people’s code is better, and/or that offering my code up for others to see will lead to rejection and ridicule.
Since I, in retrospect, made the wrong choice when cutting down a Python course to four hours and messed up the decorator exercise, I promised the attendees that I’d make a post about closures and decorators and explain it better - this is my attempt to do so.
Functions are objects, too. In fact, in Python they are First Class Objects - that is, they can be handled like any other object with no special restrictions.
When I took a look at the python.org Py3k poll, I saw that Mercurial was on the top list of things people wanted ported (though far behind the likes of Django). Now, I don’t know why others want to tie into Mercurial from code, but if a little performance overhead from using the CLI isn’t critical - such as when writing hooks, or just integrating version control in some tool or another, you might want to consider hgapi.
Recently, I wanted to migrate some lightweight services from a virtual host to an account at Webfaction, since running a wiki/issue tracker (Trac) and CI server (Jenkins) for a couple of low-volume projects really shouldn’t take a whole machine of it’s own. Or should it?
This is when I realized that Jenkins is heavyweight in a world of cloud and shared hosts. I already kinda knew, since I’ve been administrating a Jenkins installation that claims several gigs of RAM, but that’s with over thirty Maven projects and a pretty high load.
When I linked to autohook the other day, I was not prepared that somebody would actually try it, and tell me that it did not work.
So, eating my own dogfood I set up the released version of autohook, to run Blaag generation, and realized that it did, indeed, not work. This is fixed now in version 1.1.0, which also does away with using if name: …" and instead uses setuptools magic to create runnable scripts.
Tools I use every day to write better Python, to make it more fun, or just easier:
A good editor I prefer Emacs, you might like something else, but trust me on this - it’ll be a humongous project that forces you to use a full IDE. If you stay clear of large web frameworks, you might never need it. I started out using PyDev since I was used to Eclipse, but now I just don’t think its worth the complexity and overhead.