[Distutils] distlib and data files => resources ?

[a.cavallo at cavallinux.eu]

I'd be expecting these files under /usr/share/<appname> and being read only...

I don't agree with "Data files should never be installed to package
directories"... LFHS is not a religion. I can see cases where is not appropriate.

The main difference could be a library vs an application case: they have clearly
different requirements (so I'm expecting the application global config files to
be under /etc).

Someone mentioned different scenarios (app vs library, user vs system integrator
vs developer etc

I hope this helps
Thanks
Antonio

On Wed 21/11/12 04:21, "PJ Eby" pje at telecommunity.com wrote:
> On Tue, Nov 20, 2012 at 3:18 AM, Ronald Oussoren
>  wrote:
> 
> On 19 Nov, 2012, at 20:26, PJ Eby  wrote:
> >
> >
> > Data files should never be installed to package directories.  But
> Im not aware of any good reason why resource files should ever be
> installed anywhere *else*.
> 
> To be (too) snarky: because the FHS says so.
> 
> Less snarky, Linux distributors try to keep simular files together
> (for example storing all gettext translations together in
> /usr/share/locale).  To play nice in such an enviroment Python
> packages would have to install resource files outside of the python
> package and into the FHS specified directory structure.    
> Consider the example of a web page template containing embedded
> Python code.  Is that a data file containing code, or a code file
> containing data?  Where does the FHS say it goes?
> 
> What if its not embedded Python, but an embedded DSL interpreted by
> the package it goes with?
> 
> What if its not a page template, but a precompiled SQL grammar? 
> (Such as was distributed with the "gadfly" package, many a year ago.)
> 
> These are the kind of files I mean by "resources".  If somebody
> wants to support gettext or similar localization, then obviously they
> should declare the files data -- or better yet, as part of an explicit
> localization category.
> 
> The whole point of "resources" is that its a catch-all for static
> data thats more convenient to treat as a standalone source file than
> to inline as a huge triple-quoted constant in a .py file.  ;-)
> 
> 
>