Best way to find starting directory

[Dave Angel]

On 03/19/2013 10:29 AM, Frank Millman wrote:
> On 19/03/2013 14:46, Dave Angel wrote:
>> On 03/19/2013 04:21 AM, Frank Millman wrote:
>>> On 19/03/2013 09:55, Peter Otten wrote:
>>>> Frank Millman wrote:
>>>>
>>>>> I want to locate a file relative to the directory from which the main
>>>>> program was launched.
>>>>>
>>>>> I have found two ways of finding the starting directory -
>>>>>
>>>>> 1.
>>>>> import os
>>>>> dir = os.getcwd()
>>>>
>>>> This gives the current working directory...
>>>>
>>>>> 2.
>>>>> import os.path
>>>>> import __main__
>>>>> dir = os.path.dirname(__main__.__file__)
>>>>
>>>> ... and this gives the location of your main script.
>>>>
> [...]
>>>
>>> That makes sense. I usually launch the script from its own directory,
>>> but that is not guaranteed.
>>>
>>> Therefore option 2 is the way to go.
>>
>> You might want to reconsider.  There are really two different kinds of
>> data files you might want to access from your script. The first is
>> constant data that gets initialized when the script is installed.  And
>> the second is user data that he's thinking about right now.
>>
>> For example, if a script uses a saved cache of prime numbers to make
>> calculations a bit faster, it might keep that file in with its own
>> source code, or relative to it.
>>
>> And if I wanted to calculate md5 sums for a directory tree, I'd usually
>> make that my cwd before starting the script.
>>
>> Config files are somewhere in between.  In Linux, get them relative to
>> the $HOME environment variable.
>>
>> FWIW, I try to keep all the first kind of files on a separate partition,
>> and except where other programs force me, never let them leak onto the
>> OS+program partition.  That way, I'm not likely to lose an important
>> jpeg when the OS trashes its partition.  This particular paranoia is
>> left over from my Windows days, but I stick to it anyway.  It also makes
>> it easier to migrate to a new OS.  Just format the OS partition and
>> install the OS and all the apps.  The data is already separate.
>>
>
> Thanks Dave, good advice.
>
> I learnt an important lesson from Peter's response, as I did not fully
> understand the difference before. Now that I do, I am better equipped to
> make the correct decision for a given situation.
>
> As you say, there is a variety of types of data that one might to store
> externally. My current scenario is that, in my business/accounting
> application, I use xml to store form definitions, report definitions,
> etc, which are kept in the database (compressed). I am now constructing
> some xml schemas to validate the xml files. I need to store the schemas
> somewhere, so I have created a directory called 'schemas' under the main
> directory. I need to access them from various parts of the application,
> so I need a reliable way to locate the 'schemas' directory.

Rather than having various parts of the code all figuring this sort of 
thing out for themself, let them all call a common place.  If there's 
nothing in common but the directory, then save that as a global in some 
module that multiple modules can import.  But if there's more that 
could/should be shared, then make a whole module, or maybe a class, 
implemmnting that behavior.  If nothing else, it then means there's only 
one place to change when you change your mind.

>
> In theory I could store them somewhere different, and use a parameter to
> provide the path. But they are only used within the context of the
> application, so I think it makes sense to keep them alongside the 'py'
> files that make up the application.
>

In putting them there, you are making two assumptions.  One is that only 
one user will ever run this, and two is that the user will not need two 
sets of those 'schemas'.  If the user is tracking two different 
companies, each with the same code, but different xml and different 
database, this would be the wrong place to put it.  But it's up to you 
to decide those assumptions, not I.




-- 
DaveA