We Keep Coding

Register plugin for only one directory in python project

I have this python project with three directories, my_dir1, my_dir2, and my_dir3. Within my_dir1 I have defined a plugin that I would like to use for my_dir2 but not my_dir3. The problem is that even though I have configured the conftest.py for my_dir2 to register the plugin, it seems to be applied to my_dir3 as well. Since I do not want the plugin to apply to my_dir3, how do I prevent this from happening?
P.S. I should add that methods in my_dir3 are invoking methods in my_dir2

Is there a way to share common configuration using Paste Deploy?

This is a pretty simple idea conceptually. In terms of specifics, I'm working with a pretty generic Kotti installation, where I'm customizing some pages / templates.
Much of my configuration is shared between a production and development server. Currently, these settings are included in two separate ini files. It would be nice to DRY this configuration, with common settings in one place.
I'm quite open to this happening in python or an an ini file / section (or perhaps a third, yet-to-be-considered place). I think it's equivalent to use a [DEFAULT] section, or pass dictionaries to loadapp via global_conf, but that seems to be processed in a squirrelly way. For example, Kotti thinks I've properly set sqlalchemy.url, but sqlalchemy iteself fails on url = opts.pop('url'). Moreover, since Kotti defines some default settings, Paste doesn't end up searching for them in the global_conf (e.g., kotti_configurators).
I don't like the idea of passing in a large dict for %(var)s substitution, as it requires effectively renaming all of the shared variables.
In my initial experiments with Paste Deploy, it demands a "main" section in each ini file. So, I don't think I can just use a use = config:shared.ini line. But that's conceptually close to what I'd like to do.
Is there a way to explicitly (and properly) include settings from DEFAULT or global_conf? Or perhaps do this programmatically with python on the results of loadapp?

For example, Kotti thinks I've properly set sqlalchemy.url, but sqlalchemy iteself fails on url = opts.pop('url').
If you think something is odd and you're asking on SO it'd be wise to show a stacktrace and an example of what you tried to do.
Kotti gets its settings the same as any pyramid app. Your entry point (def main(global_conf, **settings) usually) is passed the global_conf and settings dictionary. You're then responsible for fixing that up and shuffling it off into the configurator.
For various reasons PasteDeploy keeps the global_conf separate from the settings, thus you're responsible for merging them if you wish.
[DEFAULT]
foo = bar
[app:main]
use = egg:myapp#main
baz = xyz
def main(global_conf, **app_settings):
settings = global_conf
settings.update(app_settings)
config = Configurator(settings=settings)
config.include('kotti')
return config.make_wsgi_app()

Global includes in Django

I want to create a module containing different utility functions and classes to use across different apps. It's not going to define any models or views. What's the best way to do this?

I would delete django-specific files like models.py, forms.py, and views.py, unless you intend to use them for their standard purpose.
From there create whatever files you want to house your custom functions/classes. I usually create an app_utils.py and put everything there. You might want to split it into separate functions.
It's really up to you. Django apps are no different from any other python package. To use methods/classes in another app you'll just use
from myapp.myapp_utils import *
Another perfectly good option is just to create a Python package yourself. All that entails is creating a directory with an __init__.py file in it.

CherryPy + Jinja, where to initialize Environment

I'm writing an application in python using CherryPy and Jinja as the template system. May be needed to say that i'm a beginner with these tools.
The problem I'm facing now is I cannot figure where to initialize Jinja's Environment class.
Currently I have
application.py (entry point, sets up Environment and starts server)
root.py (root page class for cherrypy, must be imported from 'application.py', and must import 'application.py' to retrieve instantiated Enviroment)
pages.py (other page classes for cherry.py, must import 'application.py', and must be imported from root to build the tree)
Trying to run that ends up in what seems to be a circular reference and fails (application > root > pages > application).
Should I stick to only one Environment instance or is it okay to have an instance at root.py and another in pages.py?
Which is the correct pattern for this?

You shouldn't really repeat yourself. If I were you I would create a new python module templates.py and put all the jinja environment configuration / creation there. Afterwards you can simply import that environment wherever you need it (e.g. from templates import jinjaenv). In this case you keep things simple and extensible for future use.

python single configuration file

I am developing a project that requires a single configuration file whose data is used by multiple modules.
My question is: what is the common approach to that? should i read the configuration file from each
of my modules (files) or is there any other way to do it?
I was thinking to have a module named config.py that reads the configuration files and whenever I need a config I do import config and then do something like config.data['teamsdir'] get the 'teamsdir' property (for example).
response: opted for the conf.py approach then since it it is modular, flexible and simple
I can just put the configuration data directly in the file, latter if i want to read from a json file a xml file or multiple sources i just change the conf.py and make sure the data is accessed the same way.
accepted answer: chose "Alex Martelli" response because it was the most complete. voted up other answers because they where good and useful too.

I like the approach of a single config.py module whose body (when first imported) parses one or more configuration-data files and sets its own "global variables" appropriately -- though I'd favor config.teamdata over the round-about config.data['teamdata'] approach.
This assumes configuration settings are read-only once loaded (except maybe in unit-testing scenarios, where the test-code will be doing its own artificial setting of config variables to properly exercise the code-under-test) -- it basically exploits the nature of a module as the simplest Pythonic form of "singleton" (when you don't need subclassing or other features supported only by classes and not by modules, of course).
"One or more" configuration files (e.g. first one somewhere in /etc for general default settings, then one under /usr/local for site-specific overrides thereof, then again possibly one in the user's home directory for user specific settings) is a common and useful pattern.

The approach you describe is ok. If you want to add support for user config files, you can use execfile(os.path.expanduser("~/.yourprogram/config.py")).

One nice approach is to parse the config file(s) into a Python object when the application starts and pass this object around to all classes and modules requiring access to the configuration.
This may save a lot of time parsing the config.

If you want to share your config across different machines, you could perhaps put it on a web server and do import like this:
import urllib2
confstr = urllib2.urlopen("http://yourhost/config.py").read()
exec(confstr)
And if you want to share it across different languages, perhaps you can use JSON to encode and parse the configuration:
import urllib2
import simplejson
confstr = urllib2.urlopen("http://yourhost/config.py").read()
config = simplejson.loads(confstr)