|
From: Jason B. <jb...@ze...> - 2010-01-28 20:59:19
|
On Thu, Jan 28, 2010 at 1:15 PM, Ramon Felciano <fel...@ya...> wrote: > Hello all, > > I have migrated my ad hoc configuration settings to ConfigObj and am > quite happy with how it is working out. My project includes a number > of commandline programs that all need to re-use the same configuration > settings, so I've abstracted access to the configuration data through > a config.py file that finds the INI file, loads it into a module-level > variable, and provides some utility functions to access the config > data. So far so good. > > However, I am struggling to define a cross-platform deployment set up > for configuration files that isn't brittle bootstrapping during code > startup, and was wondering how others have solved this issue. The two > issues I have are placement of the INI file itself, and the most > pythonic method for subsequently locating and loading that file. > > 1. Location of the INI files go when you deploy your project. I > imagine you want them separate from the code so you easily deploy code > updates while maintaining settings files intact. Are there guidelines > for storing this in a standardized location? E.g. next to your code? > in a project-dependent data directory? in a user-specific data > directory? > > 2. Finding the INI file from within the installed, running code. I > would like to avoid forcing users to have pass the INI file location > on the commandline. My config.py file currently searches for it in the > sys.path list, but most of these are geared toward finding code, not > settings files. For that same reason, I'm hesitant to hack sys.path to > add in data directories as well. Is there a standard location > (platform-independent or abstracted via a python lib) to find these, > similar to how the tempfile module works? > If you decide that you want to distribute it actually within your Python package, I would set it up as package data using setuptools: http://peak.telecommunity.com/DevCenter/setuptools#including-data-files The API for accessing the data is slightly annoying, but it works: http://peak.telecommunity.com/DevCenter/PythonEggs#accessing-package-resources Aside from that, I would say that the "correct" approach depends more on your program's requirements than the fact that you're using Pyhon. There are reasons to use all three ways: E.g. next to your code? > If you want to be able to configure the project on a per-installation basis, then this is the approach you would want to take. Note that there's not really any difference in this approach and the next one unless you're using virtualenv or having multiple Python installations though. in a project-dependent data directory? This is the approach to take if you want to configure settings system-wide across multiple Python installations. Personally, I feel that this would be somewhat more difficult to deploy than the previous option unless you have a valid reason to configure things across multiple Python installations and/or virtualenvs. in a user-specific data directory > This is pretty much your only choice if you want to be able to have configuration settings on a per-user basis. You probably want to begin this file name with a dot on *nix systems as that makes it invisible (which is usually preferable). |