RuntimeError: dictionary changed size during iteration
Ksenia
(Cant fill the ticket... I forgot how to register on trac. My old login
doesnt work anymore.)
After upgrading to TG 1.0 autoreload doesnt work for me anymore. When
starting any/quickstarted project with autoreloading, I get the
following traceback:
$ ./start-blah.py
2007-01-04 11:26:50,273 cherrypy.msg INFO CONFIG: Server parameters:
2007-01-04 11:26:50,274 cherrypy.msg INFO CONFIG: server.environment:
development
2007-01-04 11:26:50,275 cherrypy.msg INFO CONFIG:
server.log_to_screen: True
2007-01-04 11:26:50,276 cherrypy.msg INFO CONFIG: server.log_file:
2007-01-04 11:26:50,276 cherrypy.msg INFO CONFIG:
server.log_tracebacks: True
2007-01-04 11:26:50,277 cherrypy.msg INFO CONFIG:
server.log_request_headers: True
2007-01-04 11:26:50,277 cherrypy.msg INFO CONFIG:
server.protocol_version: HTTP/1.0
2007-01-04 11:26:50,278 cherrypy.msg INFO CONFIG: server.socket_host:
2007-01-04 11:26:50,278 cherrypy.msg INFO CONFIG: server.socket_port:
8080
2007-01-04 11:26:50,279 cherrypy.msg INFO CONFIG: server.socket_file:
2007-01-04 11:26:50,280 cherrypy.msg INFO CONFIG: server.reverse_dns:
False
2007-01-04 11:26:50,280 cherrypy.msg INFO CONFIG:
server.socket_queue_size: 5
2007-01-04 11:26:50,281 cherrypy.msg INFO CONFIG: server.thread_pool:
10
Traceback (most recent call last):
File "./start-blah.py", line 25, in ?
start_server(Root())
File "/Users/ksenia/www/3rdparty/jail/tg/turbogears/startup.py", line
300, in start_server
cherrypy.server.start()
File
"/Users/ksenia/www/3rdparty/jail/working-env/lib/python2.4/CherryPy-2.2.1-py2.4.egg/cherrypy/_cpserver.py",
line 72, in start
Engine.start(self)
File
"/Users/ksenia/www/3rdparty/jail/working-env/lib/python2.4/CherryPy-2.2.1-py2.4.egg/cherrypy/_cpengine.py",
line 91, in start
autoreload.main(self._start, freq=freq)
File
"/Users/ksenia/www/3rdparty/jail/working-env/lib/python2.4/CherryPy-2.2.1-py2.4.egg/cherrypy/lib/autoreload.py",
line 59, in main
reloader_thread(freq)
File "/Users/ksenia/www/3rdparty/jail/tg/turbogears/startup.py", line
50, in reloader_thread
modlist = [modules[modname] for modname in modules if
modname.startswith(package)]
RuntimeError: dictionary changed size during iteration
2007-01-04 11:26:50,508 cherrypy.msg INFO ENGINE: SystemExit raised:
shutting down autoreloader
2007-01-04 11:26:50,521 cherrypy.msg INFO HTTP: HTTP Server shut down
2007-01-04 11:26:50,539 cherrypy.msg INFO ENGINE: CherryPy shut down
My environment:
- OS X PowerPC
- python 2.4
- tg-admin info:
TurboGears Complete Version Information
TurboGears requires:
* TurboGears 1.0
* configobj 4.3.2
* RuleDispatch 0.5a0.dev-r2247
* setuptools 0.7a1dev-r46389
* FormEncode 0.5.1
* cElementTree 1.0.5-20051216
* PasteScript 0.9.7
* elementtree 1.2.6
* simplejson 1.3
* CherryPy 2.2.1
* TurboKid 0.9.8
* TurboCheetah 0.9.5
* TurboJson 0.9.9
* PyProtocols 1.0a0dev-r2082
* Cheetah 2.0rc6
* PasteDeploy 0.4
* Paste 0.4.1
* kid 0.9.3
* Cheetah 2.0rc6
* elementtree 1.2.6
Identity Providers
* sqlobject (TurboGears 1.0)
* sqlalchemy (TurboGears 1.0)
tg-admin Commands
* info (TurboGears 1.0)
* shell (TurboGears 1.0)
* quickstart (TurboGears 1.0)
* update (TurboGears 1.0)
* sql (TurboGears 1.0)
* i18n (TurboGears 1.0)
* toolbox (TurboGears 1.0)
Visit Managers
* sqlobject (TurboGears 1.0)
* sqlalchemy (TurboGears 1.0)
Template Engines
* kid (TurboKid 0.9.8)
* cheetah (TurboCheetah 0.9.5)
* json (TurboJson 0.9.9)
* toscawidgets (ToscaWidgets 0.1a0dev-r2224)
* genshi-markup (Genshi 0.3.6)
* genshi-text (Genshi 0.3.6)
* genshi (Genshi 0.3.6)
Widget Packages
* selectshuttle (Select-Shuttle 0.94)
TurboGears Extensions
* visit (TurboGears 1.0)
* identity (TurboGears 1.0)
* fastdata (TGFastData 0.9a6)
Greetings,
Ksenia.
Lee McFadden
the error myself, but your Trac login should be working again now.
--
Lee McFadden
blog: http://www.splee.co.uk
work: http://fireflisystems.com
skype: fireflisystems
Adam M Peacock
(fresh install of MacPython). It doesn't happen on my Windows or
Linux boxes, just my mac box.
Matthew Bevan
I too have this problem.
Matthew Bevan, Systems Administrator
Top Floor Computer Systems Ltd.
Alberto Valverde
On Jan 9, 2007, at 7:37 AM, Matthew Bevan wrote:
>
> +1
>
> I too have this problem.
Have you tried latest SVN 1.0 branch? I've reverted the offending
chageset in [2340] and should be fixed now... please reopen the
associated ticket if it isn't.
Thanks,
Alberto
Igor Foox
1.0b1).
It happens at (seemingly) random times and restarting with Ctrl-C and
'python start-myproj.py' makes it run again.
I'm also running on Mac OS X 10.4 with python 2.4.
Igor
st...@mailbag.com
intermittently and would like to make it go away. If I need to get
something out of SVN, could someone point me to some instructions on
how to do so?
-Jim
Alberto Valverde
On Jan 11, 2007, at 7:12 PM, st...@mailbag.com wrote:
> Hi: Does anyone have the fix to this problem? I am getting it
> intermittently and would like to make it go away. If I need to get
> something out of SVN, could someone point me to some instructions on
> how to do so?
>
Should be fixed in SVN since http://trac.turbogears.org/changeset/2340.
You can install TG from there by:
easy_install -U http://svn.turbogears.org/branches/1.0
(you'll need an CLI svn client I believe)
This is bugging too many people already. I think next week would be a
good time to release 1.0.1 with this bugfix plus the updated
doscstrings that will land this saturday during the docsprint and,
hopefully, an updated CHANGELOG which didn't make it into 1.0.
Any other pending bugfix which shall get in? (sorry, too lazy/busy to
look it up right now)
Alberto
Christopher Arndt
> Any other pending bugfix which shall get in? (sorry, too lazy/busy to
> look it up right now)
Yes: http://trac.turbogears.org/ticket/910
Chris
Christopher Arndt
> Any other pending bugfix which shall get in? (sorry, too lazy/busy to
> look it up right now)
Yes, you could consider: http://trac.turbogears.org/ticket/910
Chris
Alberto Valverde
Arggg! Can you *please* post that as an attachment? (Lee fixed that,
right?) I get goose bumps when I see patches pasted inside tickets'
comments... :)
BTW, I've created a new milestone (1.0.1) in Trac for that scheduled
for next friday and moved that ticket there. I also moved all tickets
from 1.0b{2,3,4} into 1.1 (quite bluntly I must admit) as those
milestones will never exist.
As soon as 1.0.1 is released I'll create a 1.0.2 and so on so tickets
can be begin "flowing down".
So now is the time to move all tickets which you thinnk shall be
included in 1.0.1 to their new milestone.
Thanks,
Alberto
Florent Aide
[...]
> Any other pending bugfix which shall get in? (sorry, too lazy/busy to
> look it up right now)
yes : http://trac.turbogears.org/ticket/1229
Florent.
Nicky Ayoub
> look it up right now)
>
> Alberto
>
yes : http://trac.turbogears.org/attachment/ticket/1115/paginate.py.diff.1a
It fixes a paginate bug when using compound widgets. Other patches on
the ticket add SA support. I understand that the patches are not
rolled in because of a lack of test cases. Since paginate itself has
no sample tests in the trunk I am hoping we can add the smaller bug
fix and hold off the more complex SA integration until someone ( with
more understanding than I ) can create proper tests.
Thanks.
--
--
Nicky Ayoub
G-Mail Account
Christopher Arndt
Oops, sorry for reposting, did not hit the cancel button fast enough...
I have reposted the patch as an attachment now.
Chris
Jeff Hinrichs - DM&T
> >
> >...
> > Any other pending bugfix which shall get in? (sorry, too lazy/busy to
> > look it up right now)
> >
> > Alberto
http://trac.turbogears.org/attachment/ticket/1234/nosetests.patch
Would be nice if the release actually passed it's own tests ;) Need to
lead by example and all that.
http://trac.turbogears.org/attachment/ticket/1231/hash.patch
-Jeff
Roger Demetrescu
On 1/11/07, Alberto Valverde <alb...@toscat.net> wrote:
> Any other pending bugfix which shall get in? (sorry, too lazy/busy to
> look it up right now)
http://trac.turbogears.org/ticket/1176
Cheers
Roger
Alberto Valverde
On Jan 12, 2007, at 2:55 AM, Jeff Hinrichs - DM&T wrote:
>
>> On 1/11/07, Alberto Valverde <alb...@toscat.net> wrote:
>>>
>>> ...
>>> Any other pending bugfix which shall get in? (sorry, too lazy/
>>> busy to
>>> look it up right now)
>>>
>>> Alberto
>
> http://trac.turbogears.org/attachment/ticket/1234/nosetests.patch
>
> Would be nice if the release actually passed it's own tests ;) Need to
> lead by example and all that.
AFAIK and IIRC TG releases have always passed all tests.... ;) I
think I'll tweak (though I wouldn't mind someone doing it for
me... ;) #1234 to use lower() as I believe those tests only fail with
Kid 0.9.4.... Hmmm, I've just upgraded to 0.9.4 and I'm seeing plenty
of "TypeError: generate_content() takes exactly 1 argument (2
given)". I think the safest solution for this would be to make
TurboKid require Kid < 0.9.4 and don't patch TG's tests with
something that will make them fail under 0.9.4.
Opinions?
>
> http://trac.turbogears.org/attachment/ticket/1231/hash.patch
I think that patch is safe enough for a stable release... :)
Alberto
Christoph Zwerschke
> AFAIK and IIRC TG releases have always passed all tests.... ;) I
> think I'll tweak (though I wouldn't mind someone doing it for
> me... ;) #1234 to use lower() as I believe those tests only fail with
> Kid 0.9.4.... Hmmm, I've just upgraded to 0.9.4 and I'm seeing plenty
> of "TypeError: generate_content() takes exactly 1 argument (2
> given)". I think the safest solution for this would be to make
> TurboKid require Kid < 0.9.4 and don't patch TG's tests with
> something that will make them fail under 0.9.4.
Alberto, the issues with Kid 0.9.4 here are the following:
1) Kid 0.9.4 output for the 'html' method used in the tests has now
lowercase tags instead of uppercase. If you want uppercase, use the
'HTML' output method.
So you have to either update your tests to check against lowercase tags
or use 'HTML' as Kid output method in the test configuration. Maybe the
tests should better use 'xhtml' instead of 'html' as output method anyway.
2) Compiled Kid templates (.pyc files in template directories) of Kid
0.9.3 are not compatible with Kid 0.9.4, they need to be recompiled.
The best solution here would be to automatically remove all .pyc files
from all Kid template directories before running the tests. This also
ensures the test is really running and uses the templates built with the
current version of TurboGears. In Kid version 0.9.5, recompilation of
templates with lower version number happens automatically, but removing
compiled templates before running the tests makes sense anyway.
I can try submitting a patch for these issues over the weekend if you
want me to.
-- Christoph
Alberto Valverde
On Jan 12, 2007, at 12:25 PM, Christoph Zwerschke wrote:
>
> Alberto Valverde wrote:
>> AFAIK and IIRC TG releases have always passed all tests.... ;) I
>> think I'll tweak (though I wouldn't mind someone doing it for
>> me... ;) #1234 to use lower() as I believe those tests only fail with
>> Kid 0.9.4.... Hmmm, I've just upgraded to 0.9.4 and I'm seeing plenty
>> of "TypeError: generate_content() takes exactly 1 argument (2
>> given)". I think the safest solution for this would be to make
>> TurboKid require Kid < 0.9.4 and don't patch TG's tests with
>> something that will make them fail under 0.9.4.
>
> Alberto, the issues with Kid 0.9.4 here are the following:
>
> 1) Kid 0.9.4 output for the 'html' method used in the tests has now
> lowercase tags instead of uppercase. If you want uppercase, use the
> 'HTML' output method.
I was aware of that....
>
> So you have to either update your tests to check against lowercase
> tags
> or use 'HTML' as Kid output method in the test configuration. Maybe
> the
> tests should better use 'xhtml' instead of 'html' as output method
> anyway.
>
> 2) Compiled Kid templates (.pyc files in template directories) of Kid
> 0.9.3 are not compatible with Kid 0.9.4, they need to be recompiled.
Aha! That explain the weird TypeError.
>
> The best solution here would be to automatically remove all .pyc files
> from all Kid template directories before running the tests. This also
> ensures the test is really running and uses the templates built
> with the
> current version of TurboGears. In Kid version 0.9.5, recompilation of
> templates with lower version number happens automatically, but
> removing
> compiled templates before running the tests makes sense anyway.
Hmm, I'm nt sure if it's a good idea to automatically remove pycs
before running the tests. No testing framework that I'm aware of does
it and I think that kind of clean up is better left to the person
running the tests (a quick "find . -name '*pyc' | xargs rm").
However, I might be wrong and I really have nothing agais automatic
cleanup so it's up to you... Reagrding the case issue I'd rather user
"lower" on the output (or use xhtml) than manually changing the case
like the current patch does because that will make sure tests also
pass for kid < 0.9.4)
>
> I can try submitting a patch for these issues over the weekend if you
> want me to.
That would be great! Thanks :)
Alberto
Alberto Valverde
On Jan 12, 2007, at 12:25 PM, Christoph Zwerschke wrote:
>
> Alberto Valverde wrote:
>> AFAIK and IIRC TG releases have always passed all tests.... ;) I
>> think I'll tweak (though I wouldn't mind someone doing it for
>> me... ;) #1234 to use lower() as I believe those tests only fail with
>> Kid 0.9.4.... Hmmm, I've just upgraded to 0.9.4 and I'm seeing plenty
>> of "TypeError: generate_content() takes exactly 1 argument (2
>> given)". I think the safest solution for this would be to make
>> TurboKid require Kid < 0.9.4 and don't patch TG's tests with
>> something that will make them fail under 0.9.4.
>
> Alberto, the issues with Kid 0.9.4 here are the following:
>
> 1) Kid 0.9.4 output for the 'html' method used in the tests has now
> lowercase tags instead of uppercase. If you want uppercase, use the
> 'HTML' output method.
I was aware of that....
>
> So you have to either update your tests to check against lowercase
> tags
> or use 'HTML' as Kid output method in the test configuration. Maybe
> the
> tests should better use 'xhtml' instead of 'html' as output method
> anyway.
>
> 2) Compiled Kid templates (.pyc files in template directories) of Kid
> 0.9.3 are not compatible with Kid 0.9.4, they need to be recompiled.
Aha! That explain the weird TypeError.
>
> The best solution here would be to automatically remove all .pyc files
> from all Kid template directories before running the tests. This also
> ensures the test is really running and uses the templates built
> with the
> current version of TurboGears. In Kid version 0.9.5, recompilation of
> templates with lower version number happens automatically, but
> removing
> compiled templates before running the tests makes sense anyway.
Hmm, I'm nt sure if it's a good idea to automatically remove pycs
before running the tests. No testing framework that I'm aware of does
it and I think that kind of clean up is better left to the person
running the tests (a quick "find . -name '*pyc' | xargs rm").
However, I might be wrong and I really have nothing agais automatic
cleanup so it's up to you... Reagrding the case issue I'd rather user
"lower" on the output (or use xhtml) than manually changing the case
like the current patch does because that will make sure tests also
pass for kid < 0.9.4)
>
> I can try submitting a patch for these issues over the weekend if you
> want me to.
That would be great! Thanks :)
Alberto
Elvelind Grandin
--
cheers
elvelind grandin
Jim Steil
-Jim
-----Original Message-----
From: turbo...@googlegroups.com [mailto:turbo...@googlegroups.com] On
Behalf Of Elvelind Grandin
Sent: Friday, January 12, 2007 6:37 AM
To: turbo...@googlegroups.com
Subject: [TurboGears] Re: RuntimeError: dictionary changed size during
iteration
Alberto Valverde
On Jan 12, 2007, at 2:27 PM, Jim Steil wrote:
>
> I've done that already and it just reappears later.
Have you tried upgrading to SVN?
easy_install -U http://svn.turbogears.org/branches/1.0
Alberto
Jim Steil
Here’s what happens when I try that. I’m not well-versed in easy-install or svn.
C:\>easy_install -U http://svn.turbogears.org/branches/1.0
Downloading http://svn.turbogears.org/branches/1.0
Doing subversion checkout from http://svn.turbogears.org/branches/1.0 to c:\docu
me~1\jsteil\locals~1\temp\easy_install-ucfqhs\1.0
'svn' is not recognized as an internal or external command,
operable program or batch file.
Processing 1.0
error: Couldn't find a setup script in c:\docume~1\jsteil\locals~1\temp\easy_ins
tall-ucfqhs\1.0
-Jim
-----Original Message-----
From: turbo...@googlegroups.com
[mailto:turbo...@googlegroups.com]
On Behalf Of Alberto Valverde
Sent: Friday, January 12, 2007 7:36 AM
To: turbo...@googlegroups.com
Subject: [TurboGears] Re: RuntimeError: dictionary changed size during
iteration
On Jan 12, 2007, at 2:27 PM, Jim Steil wrote:
Alberto Valverde
Jim Steil
Thanks Alberto. I’ve applied the patch. I’ll get back on the list if the problem pops up again.
-Jim
From: turbo...@googlegroups.com [mailto:turbo...@googlegroups.com] On Behalf Of Alberto Valverde
Sent: Friday, January 12, 2007
8:19 AM
To: turbo...@googlegroups.com
Subject: [TurboGears] Re:
RuntimeError: dictionary changed size during iteration
On Jan 12, 2007, at 3:00 PM, Jim Steil wrote:
Here’s what happens when I try that. I’m not well-versed in easy-install or svn.
C:\>easy_install -U http://svn.turbogears.org/branches/1.0
Downloading http://svn.turbogears.org/branches/1.0
Doing subversion checkout from http://svn.turbogears.org/branches/1.0 to c:\docu
me~1\jsteil\locals~1\temp\easy_install-ucfqhs\1.0
'svn' is not re cognized as an internal or external command,
operable program or batch file.
Processing 1.0
error: Couldn't find a setup script in c:\docume~1\jsteil\locals~1\temp\easy_ins
tall-ucfqhs\1.0
-Jim
-----Original Message-----
From: turbo...@googlegroups.com
[mailto:turbo...@googlegroups.com]
On Behalf Of Alberto Valverde
Sent: Friday, January 12, 2007 7:36 AM
To: turbo...@googlegroups.com
Subject: [TurboGears] Re: RuntimeError: dictionary
changed size during iteration
On Jan 12, 2007, at 2:27 PM, Jim Steil wrote:
>
> I've done that already and it just reappears later.
Have you tried upgrading to SVN?
easy_install -U http://svn.turbogears.org/branches/1.0
Hmmm, you'll need a svn CLI lient for windows... If you can't get one email me off-list and I'll send you a tarball.
Alberto
style='mso-special-character:line-break'>
Christoph Zwerschke
>> I can try submitting a patch for these issues over the weekend if you
>> want me to.
>
> That would be great! Thanks :)
Added this to ticket #1234 already though weekend has not even begun :)
-- Chris
Jeff Hinrichs - DM&T
an elegant way, much better than converting the entire string to lower
case.
-Jeff
Alberto Valverde
Great! Thanks :)
Alberto
Alberto Valverde
I've just comitted all patches that could be applied cleanly and
commented on those that couldn't. I'd appreciate the owners of those
patches I couldn't commit to take a look at them and everyone running
form SVN to upgrade to test that everything is working properly to
guarantee 1.0.1's stability (tests pass, of course...)
One thing I had to comment in many of those patches is the preferred
way of diffing, which is:
1) Checkout the 1.0 branch and "python setup.py develop" it.
2) Make your changes.
3) A *big* plus will be awarded for those tickets implementing tests
to make sure changes work as expected and prevent future regressions.
Docstrings and comments at the code will make future maintainers life
easier... (hmm, should I blush for saying that? hey! TW's docstrings
are not *that* badly documented! ;)
3.5) If a new file is created "svn add" it (even if you don't have
comitt access ATM)
4) run "python setup.py test" (or nosetests directly, first method
preferred because it's needed for setuptools namespace packages and
2.0 will most probably use them... better get used to it now.. ;) All
tests should be passing.
5) if everything passes, run "svn diff > my_patch.diff" from the
*root* of your SVN checkout. this will create a *unified* diff of
everything that changed which is easiest to apply.
6) Attach it at a ticket and include [PATCH] in the summary so i'ts
easier to spot.
Maybe this guidelines could be extended and cleaned up up a bit and
posted somewhere at the docs wiki (Karl, (Doc Wiki BDFL), where can I
do that?)
Thanks everyone working on those tickets! :)
Alberto
Karl Guertin
> Maybe this guidelines could be extended and cleaned up up a bit and
> posted somewhere at the docs wiki (Karl, (Doc Wiki BDFL), where can I
> do that?)
There's the Contributing[1] page or you can create your own and start
over. You should have an editor account regardless, I think you can
reasonably be trusted. ;]
Alberto Valverde
Christopher Arndt
> 3) A *big* plus will be awarded for those tickets implementing tests to
> make sure changes work as expected and prevent future regressions.
Is there a test framework for Ajaxian things (like CatWalk for example)?
All I can do atm to test my fix for CatWalk is to quickstart a project with
identity and do a manual functional test in the browser...
Chris
BTW Should we take this discussion to the trunk ml?
Jorge Godoy
> Alberto Valverde schrieb:
>> 3) A *big* plus will be awarded for those tickets implementing tests to
>> make sure changes work as expected and prevent future regressions.
>
> Is there a test framework for Ajaxian things (like CatWalk for example)?
There's JSUnit... :-) But we don't enforce anything.
> All I can do atm to test my fix for CatWalk is to quickstart a project with
> identity and do a manual functional test in the browser...
You can also use one of the automated test generators to record your procedure
and repeat it as a test case.
> BTW Should we take this discussion to the trunk ml?
Here there are more developers... We can move it when if we don't see more
messages or after some time with more feedback.
--
Jorge Godoy <jgo...@gmail.com>
Christopher Arndt
> One thing I had to comment in many of those patches is the preferred
> way of diffing, which is:
I would add the following steps
0) (first-time only)
- Get workingenv.py [1] and create a new environment:
workingenv.py <env>
- source <env>/bin/activate
- tgsetup.py (if this fails try this alternative approach [2])
- easy_install {nose,pysqlite,SQLObject,SQLAlchemy}
> 1) Checkout the 1.0 branch and "python setup.py develop" it.
> [...]
Using workingenv.py assures that you won't mess up your default TG setup on
your development machine when you do step 1).
Chris
[1] http://cheeseshop.python.org/pypi/workingenv.py
[2] http://smurl.name/92mc
Jorge Vargas
>
> Alberto Valverde schrieb:
> > 3) A *big* plus will be awarded for those tickets implementing tests to
> > make sure changes work as expected and prevent future regressions.
>
> Is there a test framework for Ajaxian things (like CatWalk for example)?
>
> All I can do atm to test my fix for CatWalk is to quickstart a project with
> identity and do a manual functional test in the browser...
>
> Chris
>
> BTW Should we take this discussion to the trunk ml?
yes
Jorge Vargas
> > One thing I had to comment in many of those patches is the preferred
> > way of diffing, which is:
>
> I would add the following steps
>
> 0) (first-time only)
> - Get workingenv.py [1] and create a new environment:
> workingenv.py <env>
> - source <env>/bin/activate
> - tgsetup.py (if this fails try this alternative approach [2])
> - easy_install {nose,pysqlite,SQLObject,SQLAlchemy}
>
> > 1) Checkout the 1.0 branch and "python setup.py develop" it.
> > [...]
>
> Using workingenv.py assures that you won't mess up your default TG setup on
> your development machine when you do step 1).
http://docs.turbogears.org/patching_guidelines