[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