[Distutils] using bdist_wininst --install-script

[Phillip J. Eby]

At 11:25 AM 1/27/2006 -0500, Stefan Seefeld wrote:
>Phillip J. Eby wrote:
>
> >> Unfortunately I don't think I can change the directory layout to
> >> relocate the data files into a subdirectory of my toplevel python
> >> package.
> >
> >
> > Why not?
>
>because my python modules are part of a multi-language package
>(to be more specific: a framework with multiple language bindings),
>so a number of conventions are to be respected (such as
>http://www.debian.org/doc/packaging-manuals/fhs/).

"""If an application uses a subdirectory, all architecture-dependent data 
exclusively used by the application should be placed within that 
subdirectory. For example, the perl5 subdirectory for Perl 5 modules and 
libraries."""

Sounds to me like there are only two ways to interpret this statement.  One 
leads to the conclusion that Perl or Python modules must *not* live under 
/usr/lib (since they are *not* architecture-dependent), or that it's fine 
to place data files alongside modules.  Since the former conclusion is not 
the practice, I interpret this to mean that the latter applies.

A simple thought experiment should suffice to make the point more clear: if 
you took the data files and embedded them inside a Python module using a 
string and a base64 encoding, would the module then have to live in /usr/share?

What if a C library includes static data in the library?  Does that make it 
belong in /usr/share?

What about Java jars or libraries containing resource files?  Do those go 
in /usr/share?

Since Python modules are often installed with source code, doesn't that 
mean they belong in /usr/src, with only the compiled libraries in /usr/lib?

As far as I can tell, the FHS is already interpreted quite flexibly enough 
to easily allow for embedded data files in Python packages.  Anybody who 
uses that as an excuse to denigrate your package either lacks imagination 
or is using the FHS as a political tool rather than a technical guideline.  :)