Python Projects Continuous Integration

[Harry George]

"Dave Potts" <d.j.potts at bcs.org.uk> writes:

> Hi,
> 
> I'm just starting a development project in Python having spent time in
> the Java world.  I was wondering what tool advice you could give me
> about setting up a continuous integration environment for the python
> code: get the latest source, run all the tests, package up, produce the
> docs, tag the code repository.  I'm used to things like Maven and
> CruiseControl in the Java world.
> 
> Cheers,
> 
> Dave.
> 

First, sorry to hear you have had to use Java. You should recover
after a few months in Python.  Second, welcome to Python.  Third, some
of us emacs as our IDE.

I presume you often have several packages open at once, each with its
own regression tests, own documentation, and own CVS or SVN "module".
You may also have multiple coding languages going at once (e.g.,
Python, C, C++, FORTRAN, Lisp, PROLOG).  Doing this in emacs:

1. Make a separate instance for each package being edited.  In the
   instance make separate frames for a) code buffers, b) test case
   buffers, c) doc buffers.  In the test frame, make a shell window
   where you can run go_test, thus running your testsuite for that
   package.  In the doc frame, make a shell window where you can run
   go_doc.  (Must of couse have written those go_ scripts, also done
   in emacs of course.).  

   If there are too many things happening for one desktop, run each
   package in a separate desktop (you are working in an OS which has
   virtual screens, right?).

2. Do CVS checkin/checkout in tool of your choice.  Emacs can do it. I
   prefer tkcvs, with editor set to emacs and diff set to emacs's'
   ediff.  Personal preference.

3. Do documentation in the tool of your choice.  Emacs can support
   pretty much any natural language, and has markups for just about
   any markup mechanism (SGML, XHTML, etc.).  I use my own Pdx, edited
   in emacs, and thus autogenerate HTML, PDF, LaTeX, etc.  Again,
   personal preference.  At a minimum, use some mechanism which allow
   autogeneration of documentation, auto inclusion of code snippets,
   and hyperlinking.  Since the go_doc is run in an emacs shell, use
   alt-P-return to rerun the line.  Redocumenting is thus a 2
   keystroke effort.

4. Do testing using a batch go_test script, running a suite built from
   unittest.  As needed, write debug statements to another buffer in
   that frame, where you can use full emacs functionallity to search
   it.  Since the go_test is run in an emacs shell, use alt-P-return
   to rerun the line.  Retesting is thus a 2 keystroke effort.

5. Oh, yes, coding.  Emacs's python-mode.el works fine.  Colorize or
   not as you see fit.  There are ways to set up code-completion, but
   personally I never do it.  You can setup etags but I never do --
   emacs search and grep-find do what I need.  Personal preference.

6. Use exactly the same setup for language after language, decade
   after decade, platform after platform.  Use your brain cells form
   something useful, like learning new technologies and new
   algorithms.


-- 
Harry George
PLM Engineering Architecture