While working on a more complex build I decided to make recursive imports work and clean up the syntax for imports in Vellum

Now, your imports are more explicit (just the way Python people like it) and more consistent:

imports [
    recipe(from 'scripts/testing' as 'testing')
    recipe(from 'scripts/dist' as 'dist')
    recipe(from 'scripts/sample' as 'sample')
    module(from 'vellum.commands')
]

This is the import stanza from Vellum’s build.vel file. What you see is there’s two type of things you can import, recipes and modules. Recipes are just other Vellum scripts that contain common tasks you need. Modules are Python modules that have code you need in the form of commands.

I pushed the version of Vellum that has this as version 0.14-rev85 so it’s on the Cheese Shop and in the bzr and launchpad. I would avoid it right now unless you’re interested in the latest code as it currently doesn’t load from the ~/.vellum/ directory yet so your common stuff will break.

I’ll do another release later today that brings that back.

Python Is My make

I’ve finally figured out a huge difference between what I’m doing with Vellum and what make does that turns certain types of programmers off from Vellum.

When you work with a compiled programming language like Java, C, or C++ the build tool is an essential part of your daily working. You can’t do anything without make happily building and compiling your software so you can run it.

Without make you can’t test, run, analyze, debug, or do anything. The entire chain of build junk in a compiled language is useless until you follow a large number of steps to finally produce an executable. Even if you have just one .c file you still need one additional compile step before you can run it.

(NOTE: Although tcc makes this possible, very few C coders use it.)

Another necessity is autotools. Without autoconf and friends you can’t build your software on multiple systems and still use advanced features. This makes autotools another essential thing, but only if you use a language like C that has portability problems.

In a dynamic language like Python or Ruby I don’t have this problem at all. There is no need for a make to run my program. I just run it. The interpreter is my make and does all the stuff I need to make the code I wrote work. I only violate this when I write a C extension, and even then both languages have tools that help me do that consistently.

I don’t need complex steps, or linkers, or loaders or gold from Google to happily work all day long. I don’t need things like autoconf because Python is portable unless I’m writing C extensions, and even then ctypes lets me avoid a lot of that for quite a while.

When I code, I need to run unit tests, but even that is handled for me by nose so there’s not much for me to do manually. I don’t have a build phase, I don’t have build errors, I just have code that runs or doesn’t.

I can even use Python as a debugger, a console, the works. I don’t need fancy builders and test harnesses just to see if a few lines of code work. With a compiled language I’ve had to create entire Makefile or Ant builds taking hours just to try one idea.

In essence, for programmers using compiled languages make is their Python.

For Python programmers, make is nothing more than a complicated if-statement with lots of magic.

This is why, when I wrote Vellum, it didn’t really need to know how to handle the build junk of a .c file. Vellum is higher level than this because Python already does all the crap that make does. What I needed was a tool to help automate the things Python doesn’t do like packaging, distribution, test automation, bzr management, and code generation.

To a programmer who’s entire life belongs to make this seems retarded. On the surface it seems so deficient because it can’t automagically figure out that depending on a .o file means to obviously build a .c file (unless it’s .c++, or .cpp, or .C, or .d) using cc (or gcc, or g++, or …).

Vellum obviously can do those things, assuming someone decides to write the commands needed for such magic, but why bother? I don’t do much with those languages these days, and when I do, why I’ll just write the bare minimum make necessary to build the C code and then have Vellum run that.

No point re-inventing 30 years of mythological C building lore just to keep a bunch of people happy who spend 50% of their day waiting for a program to make their program executable.

What I’ve found is that people who use make are very focused on how they can use Vellum to do what make already does. What they miss is that Vellum, unlike make, can be extended with Python to do anything you need.