Skip to main content

Whiskers - a tool for keeping track of your buildouts

Few years ago I released a first version of Whiskers together with buildout.sendpickedversions. It's about the time to push new version out.

What is Whiskers?


Whiskers is a Pyramid web application which stores information about your buildouts so that you don't have to manually check what they contain. All the data to Whiskers is transferred by buildout.sendpickedversions - an buildout extension which keeps track of packages your buildout uses and sends the data in json-format to Whiskers-server.

Reason for Whiskers?


Main reason for me to develop Whiskers was based on the need of knowing what packages I have in our servers. I'm working at the University of Jyväskylä and part of my job is to maintain our Plone instances. We have about 100 Plone instances with slightly varying setup. If we needed a new version of some specific package it meant lots of work to have a list of Plone-sites which needed the update. With Whiskers I know what to update after few clicks.

New tricks


Since last Plone conference in Arnhem I've tried to give Whiskers (and buildout.sendpickedversions) some well deserved attention and simply make it better.  Outcome of this slow process was finally published earlier this month and it has several new features:
  • Whiskers keeps track of hosts where buildouts are ran.
  • Whiskers keeps much better track of package requirements - every requirement and version is tracked.
  • Whiskers knows packages which are not used by any buildouts anymore.
  • Whiskers knows your buildouts history and has settings view where you can configure how many buildouts is being stored to DB.
  • New Twitter Bootstrap based UI.
Most above features needed a lots of changes to buildout.sendpickedversions - not to mention that things have changed a bit after zc.buildout 2.1.x release. New Whiskers requires you to use new release of buildout.sendpickedversions.

If you are using old version of Whiskers, please note that new version is not compatible with old one.

Help me to make Whiskers better


If you are using Whiskers and have ideas how to improve it, please share those ideas with me by creating a new issue in Github or send in a pull request.

Popular posts from this blog

Domain name registration through Google - when things go wrong.

Not too many people know, that you can register new domains through Google. This can be done when you're registering for Google Apps Standard Edition which is free and somewhat stripped version of their Google Apps Premium Edition. Latter one is tailored more to suit business needs.

With $10/year prize tag it's not cheapest option, but you'll get "private domain registration to protect against spam at no extra cost, full DNS control and domain management, automatically configured to work with Google services, email, calendar, instant messaging, web pages and more also at no extra charge".

As a comparsion GoDaddy offers .org domains at $14.99/year so it's actually not that bad offer. Google actually is just collecting the data and sending it to their partners (godaddy, enome) which does the registration. I decided to give it a try at January 11th. To my big surprise things didn't went that smoothly. It's been now one week since my order - the domain I …

Plone 4, ZEO and supervisor

This post belongs also to the "lessons learned" category.

With Plone 3, ZEO and supervisor combination you've probably configured your supervisor to start plone instances by running $BUILDOUT/parts/client1/bin/runzope.

Problem is that with Plone 4 your $BUILDOUT/parts/client folder doesn't contain anything else than etc folder. You know starting instances by targeting supervisor to use $BUILDOUT/bin/client1 fg doesn't work like you'd expect (supervisor would control the client1 script - not the actual plone process).

My colleague Jussi Talaskivi figured that using 'console' argument instead of 'fg' for bin/client1 script should do the trick. With 'console' argument stopping, starting and restarting Plone 4 instances with supervisor works like a charm.

Below is full example of working supervisor configuration.

[buildout] parts = supervisor [supervisor] recipe = collective.recipe.supervisor port = 8200 user = xxxx password = xxxx pr…

Usability and Plone

I've seen in here and there someone mentioning that usability of Plone is very good. Lot's of people - me included - like the fact that in Plone you don't have separate content management interface compared to some of Plones rivals. That counts for something when we're talking about good usability. Still that is only one quite small part of the whole picture. So what else is there? What do people like in Plone and where are the rough edges for end users? If general consensus is that Plone does have good usability, where is the actual proof of that?

On plone.org I found one page in developer documentation mentioning following: "Plone differentiates itself on usability. The intuitiveness of the user interface is what attracts people to Plone the most."


I interpret this sentence meaning about the "one view for all" approach. What bugs me in this is that this whole sentence about good usability is about how the UI works compared to Plones competitors. S…