Generation of script during installation
Hello,
I have a problem with distutils. During installation, I need to generate a Python module containing information about the target installation paths. For instance, if an user does:
setup.py install --install-headers=/foo
my module will have to contain something along the lines of:
headers= "/foo"
I managed to do this by subclassing install_lib (overriding method run) and generating the module there. I access the target paths with things like self.get_finalized_command("install_headers").install_dir. The module is created into the build_dir, so that install_lib.run() then copy it together with the other modules at the correct location.
This works like a charm *but* breaks when doing a bdist_wininst (and probably a bdist_rpm, I haven't checked). I'm not sure how to deal with that, as the final paths will be decided at installation time (depending on the user's system), and that's outside of the scope of my setup.py script.
Suggestions? For instance, is there a way so that the Windows installer generate an installation log, which my Python script can parse to extract the directory information?
Phillip J. Eby pje@telecommunity.com wrote:
Suggestions?
You might want to just include all your data and/or header files inside your package directory; this is the one directory you can always find at runtime, no matter how your package gets installed.
I'm not sure I understand. Are you suggesting to ignore/override what the user specifies with --install-headers or similar options?
At 07:29 PM 12/21/2005 +0100, Giovanni Bajo wrote:
Phillip J. Eby pje@telecommunity.com wrote:
Suggestions?
You might want to just include all your data and/or header files inside your package directory; this is the one directory you can always find at runtime, no matter how your package gets installed.
I'm not sure I understand. Are you suggesting to ignore/override what the user specifies with --install-headers or similar options?
I'm suggesting that if your package needs to have a reliable location for the data, then it should include it with the package. This is orthogonal to whether you *also* install the headers in a user-specified location. I'm just saying that if you have the data in your package, you no longer have to care where the user may have *also* put it.
Phillip J. Eby pje@telecommunity.com wrote:
You might want to just include all your data and/or header files inside your package directory; this is the one directory you can always find at runtime, no matter how your package gets installed.
I'm not sure I understand. Are you suggesting to ignore/override what the user specifies with --install-headers or similar options?
I'm suggesting that if your package needs to have a reliable location for the data, then it should include it with the package. This is orthogonal to whether you *also* install the headers in a user-specified location. I'm just saying that if you have the data in your package, you no longer have to care where the user may have *also* put it.
OK, so you're suggesting to install two copies of the same files: one in a fixed location (within site-packages) so that it's always accessible, and a copy for the user wherever he wants. This might work for my case, but how do I implement it? Do I need to override most of the install_* cmd to implement this logic, or there is some trick I can exploit?
Thanks!
Giovanni Bajo
Phillip J. Eby pje@telecommunity.com wrote:
You might want to just include all your data and/or header files inside your package directory; this is the one directory you can always find at runtime, no matter how your package gets installed.
I'm not sure I understand. Are you suggesting to ignore/override what the user specifies with --install-headers or similar options?
I'm suggesting that if your package needs to have a reliable location for the data, then it should include it with the package. This is orthogonal to whether you *also* install the headers in a user-specified location. I'm just saying that if you have the data in your package, you no longer have to care where the user may have *also* put it.
OK, so you're suggesting to install two copies of the same files: one in a fixed location (within site-packages) so that it's always accessible, and a copy for the user wherever he wants. This might work for my case, but how do I implement it? Do I need to override most of the install_* cmd to implement this logic, or there is some trick I can exploit?
Why not just include the header files in both install_headers and install_data (or equivalent)?
-bob
Giovanni Bajo wrote:
Hello,
I have a problem with distutils. During installation, I need to generate a Python module containing information about the target installation paths. For instance, if an user does:
setup.py install --install-headers=/foo
my module will have to contain something along the lines of:
headers= "/foo"
I managed to do this by subclassing install_lib (overriding method run) and generating the module there. I access the target paths with things like self.get_finalized_command("install_headers").install_dir. The module is created into the build_dir, so that install_lib.run() then copy it together with the other modules at the correct location.
This works like a charm *but* breaks when doing a bdist_wininst (and probably a bdist_rpm, I haven't checked). I'm not sure how to deal with that, as the final paths will be decided at installation time (depending on the user's system), and that's outside of the scope of my setup.py script.
Suggestions? For instance, is there a way so that the Windows installer generate an installation log, which my Python script can parse to extract the directory information?
wininst does create an installation log (called <packagename>-wininst.log) which is placed into the Python directory along with an uninstall .exe which takes care of removing the package if uninstall is selected in the Windows software administration tool.
However, I'm not sure whether you really need this, since only the Python installation directory is selectable during installation with wininst.
Note that it's easy to find the installation directory of an installed package by importing it and looking at the package.__path__ or .__file__.
For ZIP package imports, these two attributes include the location of the ZIP file, e.g. /home/lemburg/tmp/mxMisc.zip/mx/Misc
participants (4)
-
Bob Ippolito -
Giovanni Bajo -
M.-A. Lemburg -
Phillip J. Eby