Finding application data after install - a solution?

[Wolodja Wentland]

On Tue, Sep 22, 2009 at 07:42 -0700, Aahz wrote:
> >I want to:
> >
> >    1. Give administrators the freedom to install the data wherever they
> >       want
> >    2. Adhere to the FHS (installing data within modules breaks it)
> >    3. Be able to find that data again regardless of the installation
> >      scheme used
> >
> >1 and 2 are easily solved... It was just not possible to find the data
> >again. The snippet in the original code solves that.
> Given your mention of FHS, it sounds like you are focused on Unix-like
> systems, in which case why not rely on the standard mechanisms for config
> files?

I do not intentionally focus on UNIX type systems, but I have grown up
with *nix and I rather follow one scheme than none at all. But the
proposed way works on Windows as well, although the users might find
previously unseen directories like 'PREFIX/share/foo/doc' and the like
on their system.

How to solve this platform independently? And what standard mechanisms
for config files do you mean? Are there library functions I overlooked?

But the data I am speaking about are not config files. I will explain in
more detail so you can understand the problem.

I have a library that parses markup that has a canonical form and a
localised one. 'Image:' for example is the canonical form and the one
used for English. In German the canonical form *and* a localised one is
used ('Bild:'). This scheme (localised+canonical) holds true for all
(260+) languages this markup is used in.

The library itself works fine with the canonical forms, but loads
language specific markup definitions *if they are available* . I
therefore don't want to install this data along with the library for the
following reasons:

    1. The data is not needed if the user just want to work with English
       data

    2. The data could change much more frequently than the library that
       works with the data.

       If I couple library and data together I would have to make a new
       release *every time* the data changes, even if the user does not
       care about the other languages.

I therefore opted to provide a seperate (Python) distribution foo-data
which contains the language specific markup definitions and install it
to '$DATA_PREFIX/share/foo/languageinfo' .

As $DATA_PREFIX is only known at build time there was (until now) no
reliable way to find the data if the only information one can get is
$LIB_PREFIX, because these two might be totally unrelated.

I hope that clarifies my point

    Wolodja

P.S Which markup format am I speaking about? First one to answer gets a
brand new Internet!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 852 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20090922/9f77c3db/attachment.sig>