"Dave Potts" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
