[Tutor] What is the best way for a program suite to know where it is installed?

[Cameron Simpson]

On 22Oct2018 19:26, boB Stepp <robertvstepp at gmail.com> wrote:
>On Mon, Oct 22, 2018 at 9:47 AM Mats Wichmann <mats at wichmann.us> wrote:
>> As you've concluded by now, this isn't a completely trivial exercise,
>> and you'll possibly get asked the question "why do you think you need to
>> know that?".
>
>Actually no one has yet asked me this question, and you have me
>intrigued.  Importing the various program modules/module contents is
>no issue.  Where I believe I need to know the paths to things are to
>get to data folders, config files, and occasionally utility programs
>that I have written that are on my hard drive, but not copied to my
>current program suite.

Data folders inbuilt to your app? (I'm going to call it an "app" purely 
for convenience.) Not sure there's a universally good answer for this.  
You can include data files in your package I think (haven't tried this, 
as far as PyPI/pip goes), which means you could locate them from your 
source code.

Happy to hear more on this from others.

Config files:

I'm coming to be of the opinion, based on a couple of things I'm 
writiing at the moment, that apps should (a) come with a builtin default 
config (possibly computed form the environment the find themselves 
executed in) and that (b) that config should be expressed in a class 
instance which can transcribe itself to a file in the right format.

Why?

It solves the "where is it" problem: it is in the code, as some function 
which constructs the app's config instance in the absense of a config 
file.

It solves the "how does the user get their first config file for later 
hacking/customisation"? If the config file is not in the well known 
place (~/.your-apprc or ~/.config/something, etc) then having made your 
default config you can transcribe it to the default place. Now the user 
has a file they can modify.

It also solves the "incomplete config file" problem: if you can 
construct a default config, you can usually handle an incomplete config 
as "construct the default, then alter based on the contents of the 
config file". Which lets the user keep a tiny config file modifying only 
the stuff which needs tweaking.

Utilities:

I my opinion, unless they shift with you app it is the end user's job to 
have these in the execution path ($PATH on UNIX). If you app/package 
provides them you need a bin directory, with the same issues as your 
data files.

Cheers,
Cameron Simpson <cs at cskk.id.au>