Hi,
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?
Many thanks,
Bryn
> 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?
Hi Bryn,
If you did your install through scons; scons install, the python library should be somewhere in $prefix/lib/pythonXX/site-packages/ Where $prefix refers to the eponymous variable in your config.py and XX to the python version for which you have swiged IMP. Note that on some architectures the "lib" directory seems to be replaced by "lib64".
So, you can add the above mentioned directory to your $PYTHONPATH, 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 sets the environment, so that the rest of the line knows about IMP pathes and things. This script should dwell in $builddir/tools/ (where $builddir refers to the directory where you did run scons).
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
Hope this helps
--Ben
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
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 >
On 12/10/10 9:28 AM, Robert Brynmor Fenwick wrote: > 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.
The examples get installed along with the rest of IMP, so if you move IMP to a different location manually, it won't be able to find them any more.
> 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'
I don't see that script on that page, nor is it part of IMP currently. If you're building the latest version of IMP checked out from SVN, then you should expect things to not work from time to time. Check the nightly build status page to see what's broken.
If you're building IMP 1.0, then please refer to the 1.0 docs rather than those for the nightly build. There have been some changes which mean that example Python scripts for nightly and 1.0 are not interchangeable.
Ben
Robert,
You can fix the problem with IMP 1.0 by adding %include "IMP/saxs/FormFactorTable.h"
into modules/saxs/pyext/swig.i-in
or alternatively update to more recent version. The FoXS web server currently runs imp revision 7371, which was tested on saxs benchmark, so I recommend updating to this one.
Dina
On Fri, Dec 10, 2010 at 9:50 AM, Ben Webb ben@salilab.org wrote: > On 12/10/10 9:28 AM, Robert Brynmor Fenwick wrote: >> 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. > > The examples get installed along with the rest of IMP, so if you move > IMP to a different location manually, it won't be able to find them any > more. > >> 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' > > I don't see that script on that page, nor is it part of IMP currently. > If you're building the latest version of IMP checked out from SVN, then > you should expect things to not work from time to time. Check the > nightly build status page to see what's broken. > > If you're building IMP 1.0, then please refer to the 1.0 docs rather > than those for the nightly build. There have been some changes which > mean that example Python scripts for nightly and 1.0 are not > interchangeable. > > 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 >
Robert,
You can fix the problem with IMP 1.0 by adding %include "IMP/saxs/FormFactorTable.h"
into modules/saxs/pyext/swig.i-in
or alternatively update to more recent version. The FoXS web server currently runs imp revision 7371, which was tested on saxs benchmark, so I recommend updating to this one.
Dina
On Fri, Dec 10, 2010 at 9:50 AM, Ben Webb ben@salilab.org wrote: > On 12/10/10 9:28 AM, Robert Brynmor Fenwick wrote: >> 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. > > The examples get installed along with the rest of IMP, so if you move > IMP to a different location manually, it won't be able to find them any > more. > >> 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' > > I don't see that script on that page, nor is it part of IMP currently. > If you're building the latest version of IMP checked out from SVN, then > you should expect things to not work from time to time. Check the > nightly build status page to see what's broken. > > If you're building IMP 1.0, then please refer to the 1.0 docs rather > than those for the nightly build. There have been some changes which > mean that example Python scripts for nightly and 1.0 are not > interchangeable. > > 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 >
>> 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.
For various reasons I don't install my IMP builds in the system directories, that's probably the reason I had to resort to use the LD_LIBRARY_PATH variable. I am afraid I don't see what Is so catastrophic, and in fact I don't even see how to do it another way. If you have any hint how to do this "out-of-system" install a neater way, I'd be glad to hear.
--Ben
On 12/13/10 1:14 AM, Benjamin SCHWARZ wrote: > For various reasons I don't install my IMP builds in the system > directories, that's probably the reason I had to resort to use the > LD_LIBRARY_PATH variable. I am afraid I don't see what Is so > catastrophic, and in fact I don't even see how to do it another way. > If you have any hint how to do this "out-of-system" install a neater > way, I'd be glad to hear.
No, of course if you install in a non-system directory, you would need to set LD_LIBRARY_PATH (although it may be cleaner to edit /etc/ld.so.conf or similar). I'm just not sure that "/usr/lib64" is a good choice of non-system directory.
Ben
participants (5)
-
Ben Webb -
Benjamin SCHWARZ -
Dina Schneidman -
Dina Schneidman -
Robert Brynmor Fenwick