[Windmill-dev] Hi, and a minor suggestion

Kevin Dangoor dangoor at gmail.com
Thu Feb 14 19:07:08 PST 2008

On Feb 14, 2008, at 7:18 PM, Mikeal Rogers wrote:

> On Feb 14, 2008, at February 14, 20082:31 PM, Kevin Dangoor wrote:
>> I'm just getting started with it, and I've got a very javascript- 
>> heavy app that uses Python on the server. (Actually most of the app  
>> is static HTML+JavaScript talking JSON-RPC to the server.) My goal  
>> is to be able to launch tests from the command line, have it fire  
>> up the server and run the tests against localhost.
> You can go about this two ways;
> 1) Start your server in a setup_module() in the base test module,  
> and tear it down in a teardown_module()
> 2) Start windmill from the command line in your existing build/test  
> setup and parse the output.

Makes sense.

>> I have a suggestion (and can provide a patch, if desired). I'm  
>> using zc.buildout for my project, and that does a good job of  
>> creating a controlled installation environment. It uses the  
>> setuptools console_scripts entry point to build scripts that are  
>> guaranteed to have the correct versions of packages. The windmill  
>> script, at least, can be converted to this style script trivially.  
>> Any reason to not do this?
> We use setuptools to build the windmill Python package but windmill  
> is meant to be a standalone app more than it is intended to be a  
> Python module. We've done some serious work in the last release to  
> make windmill usable as a standalone Python package but the primary  
> use case for windmill is not as an imported python module, and in  
> fact tends to be used more often by non-Python developers.

Understood, and what I'm suggesting does not alter this. It just  
changes (improves, even) how console scripts are created. And this  
isn't a zc.buildout feature, it's a setuptools feature. Basically, you  
add to your setup() call:

		windmill = windmill.bin.windmill_bin:main

And setuptools will automatically generate a script file for you,  
including a little .exe on Windows. And, in my particular usage,  
zc.buildout will generate a modified script in the contained install  
environment's bin directory that explicitly sets all of the eggs on  
the pythonpath.

The entry point above would replace the scripts line in the setup()  
call. This feature is documented here:


> The windmill project itself doesn't gain anything by moving to  
> zc.buildout, setuptools already does what we need and is the defacto  
> standard for building and distributing Python projects.

Agreed absolutely. zc.buildout builds on setuptools for people  
deploying stuff... So, the windmill project itself wouldn't use  
zc.buildout, but users of windmill optionally could if it did  
something useful for them. (In my case, it makes it easy for  
developers working on my project to all have windmill installed, but  
our production machines don't bother, among other things.)

>> Also, I have a curiousity: I've been using Nose for more than 2  
>> years now, and this is the first I've seen of functest. I'm curious  
>> if anyone has done a comparison to what functest does vs. what nose  
>> does.
> Nose doesn't define it's own way of writing tests, it's a system  
> built around unittest and suffers from many of unittests limitations.
> Functest was written for something outside of windmill, mostly to  
> replace what I was using py.test for. Since it was used to replace  
> py.test it uses the basic py.test syntax for writing tests.

Actually, that characterization of Nose is not wholly correct. I  
realize that functest is not the topic of discussion for this list, so  
I'll be brief... Back in August 2005, I released "Testido" (http://www.blazingthings.com/dev/testido/ 
) which replaced py.test for me because py.test didn't play nice with  
setuptools at the time. In September 2005, Jason Pellerin released  
Nose which did pretty much the same thing, and I already had a big  
project of my own to maintain so I scrapped Testido...

 From the get-go, Nose has supported py.test-like features  
(setup_module, teardown_module, test_* functions). It also supports  
unittest-derived tests, doctests and a bunch of other stuff.

> It's since grown greatly in size and taken on a larger set of  
> features. Functest grew to fit the needs of modern, "functional"  
> testing and doesn't cater itself to unittests and ignores the xUnit  
> conventions.

Ignoring xUnit is a good thing :)

> The most advanced features of functest haven't been properly  
> documented but if you get me on IM or IRC I'd be more than happy to  
> go over them. The same goes for the more advanced windmill features  
> available through functest.

I'll have to take you up on that some time. Are you going to be at  
PyCon this year? Might be nice to have a little testing pow-wow.

> I hope it works great for yah.

Thanks for the quick response!


More information about the Windmill-dev mailing list