Question

As a long time Python programmer, I wonder, if a central aspect of Python culture eluded me a long time: What do we do instead of Makefiles?

Most ruby-projects I’ve seen (not just rails) use Rake, shortly after node.js became popular, there was cake. In many other (compiled and non-compiled) languages there are classic Make files.

But in Python, no one seems to need such infrastructure. I randomly picked Python projects on GitHub, and they had no automation, besides the installation, provided by setup.py.

What’s the reason behind this?

Is there nothing to automate? Do most programmers prefer to run style checks, tests, etc. manually?

Some examples:

• dependencies sets up a virtualenv and installs the dependencies
• check calls the pep8 and pylint commandlinetools.
• the test task depends on dependencies enables the virtualenv, starts selenium-server for the integration tests, and calls nosetest
• the coffeescript task compiles all coffeescripts to minified javascript
• the runserver task depends on dependencies and coffeescript
• the deploy task depends on check and test and deploys the project.
• the docs task calls sphinx with the appropiate arguments

Some of them are just one or two-liners, but IMHO, they add up. Due to the Makefile, I don’t have to remember them.

To clarify: I’m not looking for a Python equivalent for Rake. I’m glad with paver. I’m looking for the reasons.

Answer 1

Is there nothing to automate?

Not really. All but two of the examples are one-line commands.

tl;dr Very little of this is really interesting or complex. Very little of this seems to benefit from “automation”.

Due to documentation, I don’t have to remember the commands to do this.

Do most programmers prefer to run stylechecks, tests, etc. manually?

Yes.

generation documentation,
the docs task calls sphinx with the appropiate arguments

It’s one line of code. Automation doesn’t help much.
sphinx-build -b html source build/html. That’s a script. Written in Python.

We do this rarely. A few times a week. After “significant” changes.

running stylechecks (Pylint, Pyflakes and the pep8-cmdtool).
check calls the pep8 and pylint commandlinetools

We don’t do this. We use unit testing instead of pylint.
You could automate that three-step process.

But I can see how SCons or make might help someone here.

tests

There might be space for “automation” here. It’s two lines: the non-Django unit tests (python test/main.py) and the Django tests. (manage.py test). Automation could be applied to run both lines.

We do this dozens of times each day. We never knew we needed “automation”.

dependecies sets up a virtualenv and installs the dependencies

Done so rarely that a simple list of steps is all that we’ve ever needed. We track our dependencies very, very carefully, so there are never any surprises.

We don’t do this.

the test task depends on dependencies enables the virtualenv, starts selenium-server for the integration tests, and calls nosetest

The start server & run nosetest as a two-step “automation” makes some sense. It saves you from entering the two shell commands to run both steps.

the coffeescript task compiles all coffeescripts to minified javascript

This is something that’s very rare for us. I suppose it’s a good example of something to be automated. Automating the one-line script could be helpful.

I can see how SCons or make might help someone here.

the runserver task depends on dependencies and coffeescript

Except. The dependencies change so rarely, that this seems like overkill. I supposed it can be a good idea of you’re not tracking dependencies well in the first place.

the deploy task depends on check and test and deploys the project.

It’s an svn co and python setup.py install on the server, followed by a bunch of customer-specific copies from the subversion area to the customer /www area. That’s a script. Written in Python.

It’s not a general make or SCons kind of thing. It has only one actor (a sysadmin) and one use case. We wouldn’t ever mingle deployment with other development, QA or test tasks.