Latest News >> 2008-07-20 2008-06-25

I’ve been completely fed up with news/feed/rss/atom readers these days. I use Linux as my primary operating system, and I only have a few feeds that I want to rip through quick so I can get to reading the content. Yet, trying to find a reader that doesn’t suck donkey balls has been a chore.

2008-06-21

Wanna know what all the Ruby vulnerabilities are? Or at least have a fun look at how to search through code for clues? It’s a blast.

2008-06-13

I’m dropping a large blog post on everyone to just say that I haven’t died, I’ve just been busy working on my book for A/W about Mongrel. I had contracted with them to do a book about deploying Mongrel, but then decided it wouldn’t be a very good book since we’d already done one about that topic and there wasn’t too much more to say.

I blame Rage Against The Machine for today’s distraction and productivity. Between doing tons of chores and crap I managed to cram in three releases of Vellum giving it pretty big feature improvements while keeping the total code below 300 lines of Python.

Check out the Vellum project here, but I also setup a Launchpad project at https://launchpad.net/vellum for people to collaborate on the project with me. There you can download the latest, report bugs, and get at the latest code via Baazar if you can’t hit my bzr repository

The big changes that this release gives you is what I call “Strings in Python Clothes” where you can write a Python based build description, and rather than using the <<<, <—, or >>> syntax you can use functions of sh(), log(), given(), target(), and py().

All these functions do is return what you give them formatted into what Vellum wants for a build target description, but this seems to be a huge sticking point for Pythonistas. I mean, seriously I haven’t seen such a myopic dependence on arbitrary lexical elements since working with Java and C# guys. I actually received emails from people saying that if it didn’t have sh() and array syntax that nobody in Python would use it.

What I did like though was that everyone who disagreed with this syntax took the time to explain why and help me understand the culture of Python. I don’t agree with this attitude at all, being a language pragmatist and all, but I can understand it so I’ll help people out.

If you have insight into this weird obsession with everything being always in Python no matter what I’d love to hear it. From my perspective this is why so many programmers are incapable of keeping up with trends. This refusal to learn another language (or anything really) and the strange belief that an IDE will make you a better programmer (my two favorite stupidities) means that they stay slaves to what they have now and can’t formulate a perspective about what is possible.

For example, Vellum doesn’t require YAML at all, and it just uses PyYAML which is pure Python. Yet, other people seem to think PyYAML needs Syck, requires C, and other FUD they learned about two years ago. Each person had to be told (several times) that PyYAML was good for the task and they were wrong. This still lead to complaints about YAML’s syntax, even though it’s nearly the same, and then even though I pointed out they can do Python, the Python build syntax still wasn’t Python enough.

What they don’t realize is that there’s a reason I want YAML: it’s not executable. This is a huge deal when you want to distribute builds to other people but still want to keep things safer (notice I said safer not safe). Being able to grab a YAML description of the build and load it in dry-run mode with a guarantee that nothing will be run at all helps people who need to do automation of other projects.

Imagine this, with Vellum as it is you could start building other people’s projects, but before you do have it dry run and save that build output. The next time you build, do a diff on the dry-run. If the dry-run changes then don’t do it automatically, but require a human to approve it. With a simple diff of the previous build and the current build process you can trivially spot changes in the build process.

However, Python build descriptions can’t do this because they are Turing complete and a victim of the Halting Problem. In order to find out if the Python script could cause damage you’d have to solve this theoretically impossible to solve problem.

Alright, so why include Python build descriptions as an alternative? Because there’s some things that can’t be described with YAML. Things like a configuration script that analyzes the machine for the remaining build process. In this case, having a small config.py that gets imported into the larger build.yml solves the problem.

But also, it was trivial to add both and get the best of both worlds. People comfortable with YAML or who need safer builds can use YAML. People who hate YAML and need Python everywhere to be happy can use Python only builds. People who are pragmatic and want to just use whatever works best for the job can use both (like I do).

Everybody is happy hacking friends and Vellum is still small with a powerful punch.