Phillip J. Eby wrote: 

Applying LSB and FHS to the innards of Python packages makes as much
sense as applying them to the contents of Java .jar files -- i.e.,
none.  If it's unchanging data that's part of a program or library,
then it's a program or library, just like static data declared in a C
program or library.  Whether the file extension is .py, .so, or even
.png is irrelevant.
      
The FHS defines places to put specific kinds of files, such as command
scripts (/bin, /usr/bin, /sbin, or /usr/sbin), documentation
(/usr/share/doc/package-name), and configuration files (/etc).  There are
several kinds of files identified and places defined to put them.
Distribution by eggs has a tendency to scoop up all of those files and put
them in /usr/lib/python/site-packages, regardless of where they belong.
    

Eggs don't include documentation or configuration files, and they 
install scripts in script directories, so I don't get what you're 
talking about here.  For any other data that a package accesses at 
runtime, my earlier comments apply.

We've talked a bit about this before, and IIRC, at that time you (Phillip) were willing to consider patches to setuptools that allowed for the inclusion of documentation in eggs such that it was placed into an LSB/FHS appropriate directory (or some standard dir for non-LSB systems) during the install process.   I'm assuming that something similar for config files wouldn't be a problem either?  Or is this whole idea out the window given the way the discussion has trended and the reiteration above that eggs are meant to be similar in principal to jars?  


Not that I have a patch yet, but we've been working on it in our "spare time" over here at Enthought.  I'm now wondering if we're wasting our time. :-)


I think the biggest use-case confusion in the current discussion is whether we're talking about applications or libraries?  If we're talking about libraries, then clearly distribution of only executables is sufficient because anything else should be handled by the application distribution when that library is used in an app.  Whereas if we're talking about applications, you probably *do* want to include documentation, configuration info, etc. in your distribution.   I think I can sum up any further points by simply asking: "Should it be safe to assume I can distribute my application via eggs / easy_install just because it is written in Python?"


-- Dave