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:
http://salilab.org/imp/nightly/doc/html/saxs_examples.html
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
On 10 December 2010 17:52, Ben Webb ben@salilab.org wrote:
> On 12/10/10 5:44 AM, Benjamin SCHWARZ wrote: > > 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. > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-users mailing list > IMP-users@salilab.org > https://salilab.org/mailman/listinfo/imp-users >