#Python

petfeedd, the daemon I wrote for my Raspberry Pi-powered cat feeders has been updated to fix a number of bugs people were seeing attempting to install it since I originally wrote it in 2017. Perhaps the biggest change is Docker support! That’s right, if you just want to run petfeedd, now you can do it in just three commands! No more installing various libraries and things (but that approach still works as well.)

Or, how to massively over-engineer dumping cat food into a bowl. As with many of my projects, it started with something that made me angry. In this case, it was this: The Petmate Le Bistro Pet Feeder. Okay, let’s back up a little bit. Back to about 8 or so years ago. We had a cat at the time, Pumpkin, who as objectively not a good cat. She was foul tempered on the best of days and very difficult to love. But she was my wife and I’s first pet, so we did love her all the same. She had a habit of wanting food precisely on time. And if it was late, she would raise all manner of noise until she was fed. Often this came at some ungodly early time in the morning. So I bought a Petmate Le Bistro Pet Feeder.

So I’ve been doing a bit of Python recently for a project I’m working on on a Raspberry Pi. There will be a longer blog post about that in the next few weeks. But one thing I ran up against was that I wanted to start my daemon, written in Python, using a systemd service on Raspbian. Normally, you would just shove a script invocation into a systemd unit and call it good, but in my case I had made use of Pipenv, which is a bit like Bundler in the Ruby world and Composer in the PHP world, to manage my project’s dependencies.

Just a little announcement about a maintenance release to dystill. 0.2.1 has been released, which brings with it a couple of bugfixes for issues I ran into recently. First, it will now optionally try to create new maildirs when they don’t exist (this is configurable in the config file). There’s also some more error checking to hopefully prevent crazy behavior. As always, the source is on github.

I’ve finally put together a website for dystill: www.dystill.org I’ll continue to post updates about this project here, though. I’ve also finished working on a plugin for Roundcube (the popular open-source webmail client). It can be found for download at the address above.

Version (do those really matter anymore? :P) 0.2 of dystill has been released. This version brings a significant change to dystill. Namely, it breaks the unofficial association between dystill and Postfix that has existed since I first wrote it last year. I did this for a couple of reasons: To hopefully increase adoption. Dystill now (really!) stands independent of any MTA. Use it with whatever you want (sendmail, Qmail, etc). You actually always could, but you’d have to ape some Postfix tables. You don’t have to do that anymore. To make it easier to write web-based front-ends to dystill’s MySQL database, enabling users to add rules. This was done by adding an “email” column to the filters table, updating that field with the recipient address, and dropping the old user_id field. Also, a “maildir_path” config variable was added to the config, specifying where the maildirs live. There was also a minor bugfix I came across the other day where certain uncommon (but legal) characters could result in unreadable maildirs.

So it’s been awhile since I’ve written. In that time, my girlfriend has moved in here with me in Huntsville and, as always, dealnews has kept me very busy. However, it has not prevented me from occasionally trying my hand at something new. A week or so ago I decided that I was going to learn Python. However, as part of my nature, I simply can’t “learn” a language without having a purpose. For instance, I have never been able to simply read a book on programming - I needed a reason. So I’ve been giving myself reasons to do little tasks here and there in Python. One of them came to me just today. I have recently moved all of my development at dealnews from the PC to a Macbook. I’ve never been an OS-bigot - always use the right tool for the job, and the Mac - which in many ways is just Unix with pretty make-up - is the perfect platform. However, I still use many of the peripherals I purchased for my PC, including my Microsoft Natural Egronomic Keyboard that I adore. At home, I still use a PC (until I can afford a new Mac Pro), albeit with the same keyboard. One of the things I really love about the keyboard is that it has various buttons that are just … buttons. They can be mapped to do anything you want them to. There are five multi-function buttons at the top that can be mapped to run programs. So I’m sitting here thinking, “self” (because that is what I call myself), “why not write a little program to run on the click of that button and go to the next or previous track in iTunes, so that changing the music doesn’t involve any more effort out of my busy programming day than hitting an additional keystroke”. But, it must work both at home and at work, meaning that it must run in Windows and Mac. Enter Python I knew from previous experimenting in .NET that iTunes exposes a COM object on Windows. With that in mind, I quickly found this page that described almost exactly what I wanted to do in Windows. So that left the Macintosh. After an hour or so of digging on Apple’s website, I found this page that described how to access the COM on the Mac - and wouldn’t you know, the functions are slightly different. After that, it was pretty easy: import sys from optparse import OptionParser platform = sys.platform if platform == "win32": import win32com.client iTunes = win32com.client.gencache.EnsureDispatch("iTunes.Application") if platform == "darwin": from Foundation import * from ScriptingBridge import * iTunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes") def previousTrack(): if platform == "win32": iTunes.PreviousTrack() if platform == "darwin": iTunes.previousTrack() def nextTrack(): if platform == "win32": iTunes.NextTrack() if platform == "darwin": iTunes.nextTrack() def main(): parser = OptionParser() parser.add_option("-n", "--next-track", action="store_true", dest="next") parser.add_option("-p", "--prev-track", action="store_true", dest="prev") (options, args) = parser.parse_args() if options.next == True: nextTrack() if options.prev == True: previousTrack() if __name__ == "__main__": main() So yeah. It’s kind of code monkeyed together, but not bad for someone who’s only been doing Python for a week in the evenings. Passing either a -n or -p to the script causes it to command iTunes to go forward or back. Of note, to work on Windows, it does need the COM components from the Python for Windows extensions. I’m gonna expand this script some more in the future, but for now it does what I need.