This all works now. I have a further question. Has there been a change in the position of the docs? I have just tried to run the example 2 on this page:
and there are two errors relating to the location of the example files. These I can fix by hand coding the location of the files. I can not fix the final problem:
Traceback (most recent call last):
File "foxs_test.py", line 25, in <module>
ft = IMP.saxs.default_form_factor_table()
AttributeError: 'module' object has no attribute 'default_form_factor_table'
> Bryn wrote:
>> I have managed to build the python interface with swig, but fail
>> to import IMP from python. I am rather sure that I have installed
>> the modules, however I am unsure where I have to point my
>> PYTHONPATH to pick them up. The other problem might be that I don't
>> know which version of python the modules have been installed. How
>> can I work out which version and the location of the python
>> executable for which the modules were build?
If you did "scons install" you shouldn't need to play with PYTHONPATH.
The modules are made for the system version of Python (the same one that
scons uses; generally the one that comes up when you run "python" at the
command line). They should be installed in the standard Python search path.
To determine where things were installed, look at the output when you do
"scons install". It reports on every file that is installed.
If you want to build the extensions for a different version of Python,
use the scons "pythoninclude" variable to specify the directory where
Python.h lives (see "scons -h").
> If you did your install through scons; scons install, the python
> library should be somewhere in $prefix/lib/pythonXX/site-packages/
Yes, that's the default; set the scons prefix variable (default /usr) to
change that for all installed files, or just the pythondir and pyextdir
variables to move the pure Python files and Python extensions
respectively to a different directory.
> Note that on some architectures the "lib" directory seems to be
> replaced by "lib64".
"seems to" is an odd way of describing it. On x86_64 systems, it is,
since many Linux variants put 64-bit libraries in /usr/lib64 rather than
/usr/lib. You can set the libdir, pythondir and/or pyextdir variables if
this isn't what you want on your system.
> or alternatively you can run python or your IMP enables python
> scripts using the imppy.sh script imppy python myscript.py
The imppy.sh script is used to test IMP in the build directory; once
it's installed correctly you shouldn't need it.
> Ultimately, on some architectures and depending on where I did place
> my IMP stuff, I had to add $prefix/lib64 to my LD_LIBRARY_PATH
That sounds like a recipe for disaster! If your system doesn't use
/usr/lib64 for 64-bit libraries, simply set the libdir scons variable to
/usr/lib.
-- R. Bryn Fenwick " target="_blank"> Post-doctoral fellow Chemistry and Molecular Pharmacology Programme
Institute for Research in Biomedicine (IRB Barcelona) Parc Científic de Barcelona Baldiri Reixac 10, 08028 Barcelona, SPAIN Tel. (+34) 9340 20460