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!
signature.asc
Description: Digital signature
-- http://mail.python.org/mailman/listinfo/python-list