[Grok-dev] making generated startup.py smaller

Martijn Faassen faassen at startifact.com
Tue Jan 13 11:05:34 EST 2009


Hi there,

The new paster enabled grokproject generates a startup.py file that sets 
up various things.

Now I don't like code generation where it can be avoided, and it looks 
like there's some stuff in startup.py that could go into a library instead.

We have a few options. We could put this code into grok itself. This 
would require that certain versions of grokproject *have* to have a 
recent-enough version of Grok, but I think that this is acceptable. If 
we move it into grok itself, I propose a grok.startup module.

Alternatively we could consider a grokcore.startup package that contains 
this code instead - with a bit of care this could make newer versions of 
grokproject still compatible with older versions of Grok as it'd put in 
a setup.py requirement for grokcore.startup. The Grok core would also 
have this requirement, so if newer versions of Grok are installed it 
doesn't need to add grokcore.startup into the project's setup.py anymore 
(grokproject could detect this).

Having thought about it I think the second option is nicer.

Let me go through startup.py bit by bit and offer my commentary:

def application_factory(global_conf):
     zope_conf = os.path.join(global_conf['zope_conf'])
     return zope.app.wsgi.getWSGIApplication(zope_conf)

This is a relatively small bit of code. I think people need to be able 
to edit this to add new WSGI middleware to their application (if they do 
not want to use paste for some reason), correct? If this is not intended 
to be edited at all, this whole function could go into Grok itself, as 
global_conf drives matters, correct?

def 
interactive_debug_prompt(zope_conf='/home/faassen/projects/grokexample/etc/zope.conf'):

the hardcoded path to something in my home directory isn't right. This 
means that code that relies on this path cannot be exchanged between 
developers. Perhaps this is what Andreas Jung was referring to earlier? 
I consider this a bug we should get rid of as soon as possible.

https://bugs.launchpad.net/grok/+bug/316794

     db = zope.app.wsgi.config(zope_conf)
     debugger = zope.app.debug.Debugger.fromDatabase(db)
     # Invoke an interactive interpreter shell
     banner = ("Welcome to the interactive debug prompt.\n"
               "The 'root' variable contains the ZODB root folder.\n"
               "The 'app' variable contains the Debugger, 
'app.publish(path)' "
               "simulates a request.")
     code.interact(banner=banner, local={'debugger': debugger,
                                         'app':      debugger,
                                         'root':     debugger.root()})

This all looks like entirely generic code that should go into a reusable 
package. I don't think people will be editing this a lot, right?

class ControllerCommands(zdaemon.zdctl.ZDCmd):

     def do_debug(self, rest):
         interactive_debug_prompt()

     def help_debug(self):
         print "debug -- Initialize the application, providing a debugger"
         print "         object at an interactive Python prompt."

More code that can go into a library.

def 
zdaemon_controller(zdaemon_conf='/home/faassen/projects/grokexample/etc/zdaemon.conf'):

another hardcoded path, I reported it in the same bug.

     args = ['-C', zdaemon_conf] + sys.argv[1:]
     zdaemon.zdctl.main(args, options=None, cmdclass=ControllerCommands)

This looks also like generic code that can go into a library.

The issue of moving code into a generic library I've also filed here:

https://bugs.launchpad.net/grok/+bug/316799

I've assigned both issues to Michael Haubenwallner as he is the main 
WSGI integrator, in the hopes that he is interested in working on this.

Regards,

Martijn



More information about the Grok-dev mailing list