[Tutor] Configuaration files and paths?

[Dave Angel]

Allen Fowler wrote:
>>> What is the recommended way to configure my application find the various 
>>>       
>> database and/or configuration files it needs?
>>
>> Recommemded by whom? A lot depends on the OS. Apple for example have one set of 
>> recommendations for MacOS, Windows has another and Linux has several to choose 
>> from!
>>
>>     
>
>
> Thank you.... good point.
>
> Planning on using a ConfigParser based .ini file located in the ./config folder.
>
>   
>>> For instance my folder layout:
>>>
>>> /path_to_app/app.py
>>> /path_to_app/lib/
>>> /path_to_app/database/
>>> /path_to_app/config/
>>> /path_to_app/photos
>>>
>>> .... and so on.  I would like to make an .ini in the config folder 
>>>       
>> Seems fair enough, however on a Unix system you should also consider allowing 
>> the user to have their own personalised version in their home directory. Thus at 
>> startup you get the current user ID / home directory and look for a suitable 
>> config file. If it exists read it, if not read the default one in your config 
>> directory.
>>
>>     
>>> 1) How does my main app file find the config file in the first place?
>>>       
>> Generally use a relative path so normally your app will run from its home folder 
>> so you can look in ./config. You might also set a system environment variable - 
>> for example the CLASSPATH or PYTHONPATH variables, or the ORACLE_HOME used by 
>> Oracle for their database. If the environment var is not set then look in 
>> ./config
>>
>>     
>
> Assuming the application could be invoked in odd ways that may alter the notion of the current working directory, how do I unambiguously find the absolute path to the current python source file?  (So I can load the nearby .ini)
>
>
> As a follow-up question, how do give my modules stored under ./lib access to the data in my ConfigParser object?  (For instance, database connection string, storage path, etc.)
>
> I guess a global ConfigParser object would work, but that seems wrong.
>
>
>   
Regardless of the OS, you need to consider whether more than one user is 
going to share the code and constant data, but have independent versions 
of the variable data.  If so, then putting the .ini file in the code 
tree makes no sense.  You also have to decide whether there is going to 
be an install process, or whether the program files will be simply 
unzipped or copied to a single target directory.  And if there is an 
install, the library you use could very likely influence what you wind 
up doing.

But for raw answers:    you can tell where a running python module is 
located, simply by using the __file__ attribute.  You can then parse 
this with os.path.dirname() to get the directory the file is located 
in.  Then you can use ..\config to get to the config directory.  You're 
right;  don't use current directory to find any of this.  Use it to find 
user data, usually, if the command is entered interactively.  And don't 
use it at all, for things started by Explorer (in Windows).

I would expect to have two directory structures, one fixed, and one 
variable.  The fixed one is stuff that doesn't get modified once 
install  (or copy) is complete.  And the variable one is derived in some 
way from the user's login.  On Windows, that could be a registry entry 
(HKCU), or it could be the HOMEPATH ( c:\Documents and 
Settings\username, on XP ).  Once you've calculated this initial 
variable directory, create an INI file that says where all the rest of 
the variable data is.  I claim that this would be an absolute path, set 
up the first time the user runs  File->Configuration.   The default 
would be relative to the same directory, but it should be changeable.

I try to set up my personal systems with two main partitions.  One has 
(mostly) constant data and programs, modified each install.  It also has 
junk, like temp files, the swapfile, etc.   All user data is on a 
different partition, with very different backup rules.  Windows puts my 
HOMEPATH on the C: drive, but I avoid programs that force me to leave 
any quantity of information there.

As for how various library modules should find data gathered in your 
main script, you just pass an instance of the object containing that data.


DaveA