using bdist_wininst --install-script
Hi there, I'm working on a python application which uses a number of data files. In order to figure out the path to the data files I used to use some hacks, such as letting the application file inject a 'prefix' variable into the root module (package) for other modules to use. This was, IIRC, required since on some systems (notably windows) the actual prefix could differ from any variable set during the packaging stage (since it's the user's choice to override it). Now I read about the '--install-script' option that sounds as if it could solve my problem (on windows). Can anybody comment on this ? How can I use it to fix up 'prefix' variables at installation time ? I'v found the documentation at http://www.python.org/doc/2.4.1/dist/postinstallation-script.html, but that doesn't mention what parameters are available to the script (beside the 'install' / 'remove' flag). Any help is highly appreciated ! Stefan
At 09:41 PM 1/25/2006 -0500, Stefan Seefeld wrote:
Hi there,
I'm working on a python application which uses a number of data files. In order to figure out the path to the data files I used to use some hacks, such as letting the application file inject a 'prefix' variable into the root module (package) for other modules to use.
The simplest way to do this is to use the package_data option, see: http://docs.python.org/dist/node11.html And then use the __file__ variable of the containing package module to determine the data file locations at runtime. So, if a data file 'bar.dat' is inside your 'foo' package, you can use: import foo pkg_dir = os.path.dirname(foo.__file__) filename = os.path.join(pkg_dir, 'bar.dat') This will work on any platform, with any installation method, bdist_wininst or otherwise. The package_data option was introduced in Python 2.4; if you are using Python 2.3 you can use setuptools instead. There are also hacks out there for even earlier versions of Python that accomplish the same thing, but they're more difficult to implement. Still, even those are far easier than what you're contemplating doing with bdist_wininst.
Hi Phillip, Phillip J. Eby wrote:
At 09:41 PM 1/25/2006 -0500, Stefan Seefeld wrote:
Hi there,
I'm working on a python application which uses a number of data files. In order to figure out the path to the data files I used to use some hacks, such as letting the application file inject a 'prefix' variable into the root module (package) for other modules to use.
The simplest way to do this is to use the package_data option, see:
http://docs.python.org/dist/node11.html
And then use the __file__ variable of the containing package module to determine the data file locations at runtime. So, if a data file 'bar.dat' is inside your 'foo' package, you can use:
import foo pkg_dir = os.path.dirname(foo.__file__) filename = os.path.join(pkg_dir, 'bar.dat')
This will work on any platform, with any installation method, bdist_wininst or otherwise.
IIUC, this works if and because 'bar.dat' is located somewhere under pkg_dir, right ? The traditional way of installing 'data files' on unix-like systems, however, is to keep them in <prefix>/share, and the python modules in <prefix>/lib/python-<version>/site-packages, and there doesn't appear to be a platform-independent path from python module to data dir. Right ? Unfortunately I don't think I can change the directory layout to relocate the data files into a subdirectory of my toplevel python package. Thanks anyways, Stefan
At 10:25 PM 1/25/2006 -0500, Stefan Seefeld wrote:
IIUC, this works if and because 'bar.dat' is located somewhere under pkg_dir, right ?
Yes. This is pretty much the only sane way to bundle read-only data files with a Python package.
The traditional way of installing 'data files' on unix-like systems, however, is to keep them in <prefix>/share,
I believe that's only if they're read-only, in which case there's no reason not to put them in a package directory, tradition notwithstanding. :)
and the python modules in <prefix>/lib/python-<version>/site-packages, and there doesn't appear to be a platform-independent path from python module to data dir.
Which is why the sane way to do it for Python is to put them in a package directory; it ensures that you can find them using the same code regardless of platform.
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?
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/). Regards, Stefan
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. :)
Phillip J. Eby wrote:
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.
Sorry, may be I didn't express myself very clearly; I'll try again. I have a number of 'architecture-independent' files that are used by different parts of the framework, such as python modules, C++ libraries and applets, etc. I can't see any good reason why my C++ code (which doesn't even know that there are python modules as part of the same framework) should look for its data in some obscure 'site-package' directory. :-) The canonical way for such data files is still <prefix>/share. Regards, Stefan
At 05:00 PM 1/27/2006 -0500, Stefan Seefeld wrote:
Sorry, may be I didn't express myself very clearly; I'll try again.
I have a number of 'architecture-independent' files that are used by different parts of the framework, such as python modules, C++ libraries and applets, etc. I can't see any good reason why my C++ code (which doesn't even know that there are python modules as part of the same framework) should look for its data in some obscure 'site-package' directory. :-)
Ah. :) Maybe the best solution then would be to have a way to generate C++ and Python (and whatever other language) modules with the data embedded in them, then, so that none of them have to worry about locations. :)
participants (2)
-
Phillip J. Eby -
Stefan Seefeld