[pony-build] extended command-line options for build scripts

[C. Titus Brown]

Wow, when you send an e-mail, you really send an e-mail with content :).

On Thu, Feb 11, 2010 at 04:46:49PM -0500, Jack Carlson wrote:
> - The python executable used for building can be changed via command line with the -e option.  Note that adding the new python executable name to the arguments list without the -e option will no longer work--it will cause the build script to error out instead.  Also, the version of python used no longer needs to be set in the build script--a default value is set in pony-client.  This of course can be easily overridden, but should cut down on redundant information.
> [ http://github.com/JackCarlson/pony-build/commit/5cbfe68cc5778d4c69f92cd50b139ddf07e4bb2b ]

Hey Jack,

good work!  A few comments, though.

First: Is it appropriate to have Python-specific behavior specified on the
command line?  Sure, pony-build is written in Python, and I'm planning to
mainly use it to build Python packages, but just imagine if it becomes wildly
successful and Ruby, Java, C++, etc people start to use it -- will we add a
separate set of command-line flags to "standard" build scripts to allow
language- or environment-specific settings to be passed in?

And can you think of any other ways to specify this kind of configuration
detail?

(There's no right answer, here, just things to think about.  If I could
think of a simple right answer I would have just implemented it that way ;)

Second, you have an awful lot of commented out lines of code in your
commit.  What's with that?  Just get rid of code that you don't need any
more; git can always retrieve old code.

Finally, I haven't always followed this suggestion myself, but: commit messages
are traditionally one line (< 80 char) followed by a blank line, followed
by more detail.  This makes it easy to see what a particular commit did
without having to wade through a whole paragraph.

> - Tags can now by set via command-line with the -t option.  Enter tags as a comma-delimited list (not space-delimited, for obvious reasons).
> [ http://github.com/JackCarlson/pony-build/commit/13367b31d87204a4b85ab7312d7deab4ecad4c89 ]


Great!  And good find on the coordinator bug -- this code can be made
simpler like so,

	tags = list(client_info.get('tags', []))

I am going to make an aesthetic ruling that empty tags should default
to no tags at all, not a single tag of 'unknown', too.  Could you change
the code to reflect that?

Ditto with this 'if' statement:

  if options.tagset != []:

can simply be:

  if options.tagset:

> - The build scripts should be able to verify if the given version of python actually exists on the system.  If it does not, a warning will be displayed and the build script will exit.
> 
> I don't have a link for this latest push, as github doesn't seem to be reflecting the change yet--but my machine is insisting that everything is "up-to-date".

Looks like this is it:

http://github.com/JackCarlson/pony-build/commit/9748bd06aa1a2a89dfa22b9cc4920dfbe9a7f29e

Why not use subprocess instead of popen?

And WhatsWithTheCamelCaseFunctionName?
Isn't_good_old_lowercase_with_underscores good enough for you?

Seriously, for straight function names, use lowercase_with_underscores.
Class names can be CamelCase.

> What next:

[ ... ]

Do you have any suggestions on how to write automated tests for any of the code
you've just added? :)

> One thing I'd like to tackle next (if there aren't any more pressing issues) is the structuring of the build scripts and of pony-client.py itself.  I feel there is a lot of redundant code/variables in these build scripts, and think almost all the code in the build scripts could be moved into a pony-client class.  Variables such as the default pony-build server to be used, default python executable, etc could be stored in a config file.  With these changes, it'd be possible to get the build scripts down to just a couple lines of code each, but still be just as configurable as they are now.

I would be interested in seeing your reimagining of the build scripts!  Please
do it on a separate branch though -- all of your changes above will get
committed to my master, but I make no guarantees of your reimagining.

I've been thinking that build scripts could be written in a simple twill-like
language, too..

> One argument against this that I can think of is what if the build environment changes much--for example, the default version of Python changes to a newer version, then the users would have to go back and update every build script if they were relying the default before (if that makes sense?).  Not sure if this would be a big issue though, as any dedicated build system that would have enough build scripts to make this an issue should probably be a stable environment anyway.  Also, if this were a foreseeable outcome, the build scripts should probably have been written to override the default python version from this config file in the first place.
> 
> Any other thoughts/ideas about this?

Why not make the default version whatever is on the path as 'python', and
allow build scripts to set a default?  (This gets back to my question about
command line parameters, etc.)

> One other question (aimed at Titus, but if anyone else knows, let me know!): what is a "stale build", and what is the "request build" link actually supposed to do?

A "stale build" is one for which no new information has been received within
the last 24 hours.  By default, pony build clients won't try to rebuild a
package until it's stale; the '-f' flag forces a build.  'request build'
just sets the 'this package is stale' flag.

cheers,
--titus
-- 
C. Titus Brown, ctb at msu.edu