0

When attempting to install a program using scons, I get the following output: "ImportError: No module named SCons.Script" and the install fails. I've installed scons and the third party source, ensured permissions are properly set, and verified paths. I see one other entry in SO with a similar (but not exactly the same) problem, but no solution. Can anyone suggest solutions?

Scons install command: python setup.py install --prefix=/path/to/software/

Software install command: ./scons.py -j<number_of_processors_to_use> mode=release bin

Target software: Rosetta (Rosetta)

StephenDonaldHuffPhD
  • 780
  • 6
  • 18
  • How did you install SCons (Command line)? How are you invoking scons (command line)? What program/package are you trying to install via SCons? (URL?) – bdbaddog Sep 20 '16 at 22:25
  • This information is in the answer. I'll move it up to the question. – StephenDonaldHuffPhD Sep 21 '16 at 12:44
  • Where is the scons.py located? Typically you'd run scons which would be in /path/to/software/bin/scons and not scons.py if you install via the method specified. In that case the python paths should be o.k. and you shouldn't get the error you're seeing. – bdbaddog Sep 23 '16 at 17:44
  • The problem in this regard is probably best related to the third party software, in that you must chose an execution location (which does not have the associated install files) or an installation location (which does not have scons in the symlink format with appropriate path). Since this is not the only software that induces this issue (apparently, several implementations rely on symlink structures for pathing), and since I spent many hours researching the solution and could not find one on SO, I posted here. – StephenDonaldHuffPhD Sep 27 '16 at 13:11
  • Isn't SCons being installed into : /path/to/software/bin/scons ? (note the absense of .py) – bdbaddog Sep 28 '16 at 15:54
  • Yes, it's in the right path. That's not the problem. I'm working on three supercomputers. Two have the same configuration, apparently, and the install works. The third apparently does not allow the tarzip/extract process to create SYMLINK files. In fact, the scons file is in the right place AND it has the right name, but it's not a SYMLINK file. Since this appears to be some quirk of a SPECIFIC Linux installation and I have seen the problem unresolved elsewhere, I posted the answer: when someone gets this error, they should inspect the scons file to be sure it is a SYMLINK file. – StephenDonaldHuffPhD Oct 06 '16 at 13:38
  • Did you try using a virtualenv and then using pip install scons? – bdbaddog Oct 07 '16 at 03:46
  • This appears to be a proposed solution to Python issues. The problem here is not related to Python, per se, rather it is manifest in the HPC configuration, which prevents the tar/zip process for establishing necessary symlinks during extraction. Once the symlink is reestablished, there are no Python issues. – StephenDonaldHuffPhD Oct 09 '16 at 14:18

1 Answers1

0

The solution I found is related to the OS (Linux SLES 11) configuration, I believe. At any rate, when I unpack (using the preserve permissions switch) and install scons (python setup.py install --prefix=/path/to/software/), everything runs without a problem. After much research and review, however, I noticed that the 'scons.py' file on one machine where the install works is a symlink file, while on the target machine, the file is standard (the OS apparently blocked creation of the symlink during setup). The solution, then, is to remove the non-symlink scons.py file, and then recreate the symlink using the syntax 'ln -s /path/to/file /path/to/symlink' (How to symlink a file in Linux?)

In this specific case, the syntax was 'ln -s external/scons-local/scons.py scons.py'. Where the 'external' folder contained the third-party scons implementation.

Community
  • 1
  • 1
StephenDonaldHuffPhD
  • 780
  • 6
  • 18