At 12:34 AM 12/5/2009 +0100, Andrew Dalke wrote:
I had some concerns about them. For one, all of the plugins define
out-word facing web services on our server. If the plugins can be
located in arbitrary locations inside of site-packages, how does the
administrator know which plugins will be activated? How does the
admin enable/disable a plugin for testing or security reasons,
except by changing the entire package installation?
Then install the plugins as eggs to the plugin directory, rather than
installing them in site-packages.
If the admin wants to change the URL for a given service from
"/spam" to "/spam_and_eggs", which is currently done as
configuration data in the installed plugin, file, that is, by changing
# default service name is base on the function name. This becomes "/spam"
@simple_service("GET", "http://protocol.id/";)
def spam():
return "Spam!"
-to-
@simple_service("GET", "http://protocol.id/";, "spam_and_eggs")
def spam():
return "Spam!"
It does not seem like changing the installed package will be so simple.
Indeed. It would be much better to make your service decorator read
overrides from a configuration file, so that the decorator values are
merely defaults. Editing source code is a lousy way to do
configuration, when there's stuff in the file besides configuration.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
