Installing applications
I know that I don't read a lot of what goes on in our manuals, newsgroups and sigs, so if this problem has a known answer I would appreciate a pointer. Distutils solves the "install a package" problem. Now, how do we solve the "make it an application" problem? Here is what I mean. I have a Python package with a driver routine inside. I need some way of starting up Python with that script as the input. So I end up writing something like this example from the Pyfort package, file pyfort: #!/usr/bin/env python import Pyfort.driver import sys Pyfort.driver.run(sys.argv[1:]) The first problem for me is that this chooses the python on the path, not necessarily the python into which I have installed this package. In our environment we have multiple Pythons since we version our software package. So if someone runs "pyfort" all is well, but if they do /usr/local/cdat/experimental/bin/pyfort <args> but their path finds /usr/local/cdat/public/bin/python, the import Pyfort.driver gets the "public" rather than the "experimental" version. But if I hardwire the path into the first line, I can't tar it up and send it to somebody somewhere else. (Like to my customers, for example). Python has a -c option, but I can't expect the users to cram the above into a -c line. The second problem is that I had to write (and more seriously, install) this little file in the first place. Seems dumb when all I want is the effect of python /usr/local/cdat/experimental/lib/python1.5/site-packages/Pyfort/driver.py <args> We have another app where essentially we want to run python, import some stuff, and go to the prompt.
"Paul F. Dubois" wrote:
I know that I don't read a lot of what goes on in our manuals, newsgroups and sigs, so if this problem has a known answer I would appreciate a pointer.
Distutils solves the "install a package" problem. Now, how do we solve the "make it an application" problem?
In general, this is an unsolved problem. We have it too since we are shipping a major Python app to customers, as well as using this app and a few others internally. See: ftp.interet.com/pub/bootmodule.html ftp.interet.com/pub/pylib.html
#!/usr/bin/env python import Pyfort.driver import sys Pyfort.driver.run(sys.argv[1:]) The first problem for me is that this chooses the python on the path, not necessarily the python into which I have installed this package. ... But if I hardwire the path into the first line, I can't tar it up and send it to somebody somewhere else. (Like to my customers, for example).
As a Windows dweeb, it took me a while to understand this. It looks like you have compiled the various Python versions with a different $prefix, so each carries its own custom PYTHONPATH. Otherwise the Python binary used can not affect which version of Pyfort/driver.py gets imported. Although the directory of the Python binary is appended to PYTHONPATH, these are all bin directories, and the packages are in lib directories so the modification to PYTHONPATH doesn't matter. The directory of the Python script is prepended to PYTHONPATH so specifying a script name almost works. The problem is that you put pyfort.py into a bin directory too, so prepending this to PYTHONPATH does not help get the package from the lib directory either. I think if you move pyfort to the lib directory it will work. But you must still specify which pyfort you want. If the lib directory is on PATH, "pyfort" works. For a different pyfort, you will need to specify the whole path. I am not sure I have understood this correctly, so please complain if I did not. Jim Ahlstrom
participants (2)
-
James C. Ahlstrom -
Paul F. Dubois