installation appears to require python executable be in /usr/local

[rsharris]

Howdy,

I'm following the installation steps described in the progressiveCactus readme (clone, pull, submodule update, then make). When I attempt "make", it quickly fails the assert at line 1134 in submodules/virtualenv/virtualenv.py.

It apparently doesn't like the fact that my version of python is inside my home directory hierarchy, and instead it wants it to be somewhere under /usr/local.

That seems like an odd requirement. Does it have something to do with trying to figure where/how to install other python packages?

As a non-admin, I don't have write access to /usr/local. I built python 2.7 from source, rather than having an admin do it for me.

Bob H

[joelarmstrong]

Hi Bob,

This is weird--I definitely have my python installed under my home directory as well, and it works for me. Let me take a look at this assert later tonight and see what's up.

[rsharris]

Howdy, Joel,

Not urgent, especially not urgent enough to eat into a holiday weekend. I won't be doing anything with this myself until Tuesday at the earliest.

Thanks, Bob H

On Sep 4, 2015, at 6:10 PM, Joel Armstrong notifications@github.com wrote:

Hi Bob,

This is weird--I definitely have my python installed under my home directory as well, and it works for me. Let me take a look at this assert later tonight and see what's up.

— Reply to this email directly or view it on GitHub.

[rsharris]

The problem is that I messed up my python build (over two years ago). While my python is in /home/me/python/linux-x86_64/Python-2.7.4/ , sys.prefix is "/usr/local". change_prefix is trying to change the prefix of /home/me/python/linux-x86_64/Python-2.7.4/Lib/os.py to /home/me/cactus/progressiveCactus/python, and it can't figure out which parts of the path it should replace (I guess), because sys.prefix returns "usr/local".

I looks like I was supposed to have set that up when I built my version of python, using the --prefix option to the configure script. It's a little surprising I haven't noticed this problem before, since I've been using that python executable for a couple years. But wrong it is -- I'll rebuild my python and proceed from there.

Thanks, Bob H

[joelarmstrong]

Hi Bob,

Great--glad this worked out OK. Let me know if you have any other trouble.

[rsharris]

I've finally gotten back to this. I rebuilt my python and correctly set the --prefix option when building that (also upgrading from 2.7.4 to 2.7.10). This has gotten me past the problem in my Sep/8 email, but the "make" quickly runs into another one. I have appended the output from make, below my sig.

I believe the PYTHONHOME stuff is a red herring. If I follow the suggestion in line 7 to set PYTHONHOME (to /home/me/python/linux-x86_64), that message goes away but the rest of the output is (I believe) the same. So for the run that produced this log, PYTHONHOME isn't set.

One source of frustration is that I cannot find the modules that are outputting any of the informational messages here (other than the modules identified in the traceback). If I could find the module telling me what it thinks about sys.prefix, I might be able to figure out ... something. I have tried searching the cactus directories for pieces of that error text, but to no avail. From the command line python shell, sys.prefix is /home/me/python/linux-x86_64.

Further, the failed attempt to import _sysconfigdata is hard to decipher. If I fire up python from the command line, there is no problem with that import: $ python Python 2.7.10 (default, Oct 5 2015, 16:35:54) [GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

from _sysconfigdata import build_time_vars len(build_time_vars) 532

So this would suggest something is mucking with where python is looking for that module. Which is no surprise for anything involving virtualenv. But as I am unable to locate the mucking modules I'm unable to make any guesses about how things have been mucked up.

Here are the commands I did, starting from a fresh pull from github yesterday: cd /home/me/cactus git clone git://github.com/glennhickey/progressiveCactus.git cd progressiveCactus git pull git submodule update --init make

Thanks for any help. Bob H

make[1]: Entering directory /home/me/cactus/progressiveCactus/submodules' rm -f /home/me/cactus/progressiveCactus/submodules/../environment python /home/me/cactus/progressiveCactus/submodules/virtualenv/virtualenv.py /home/me/cactus/progressiveCactus/python New python executable in /home/me/cactus/progressiveCactus/python/bin/python Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] Traceback (most recent call last): File "/home/me/py/lib/python/site.py", line 75, in <module> __boot() File "/home/me/py/lib/python/site.py", line 35, in __boot imp.load_module('site',stream,path,descr) File "/home/me/python/linux-x86_64/lib/python2.7/site.py", line 548, in <module> main() File "/home/me/python/linux-x86_64/lib/python2.7/site.py", line 530, in main known_paths = addusersitepackages(known_paths) File "/home/me/python/linux-x86_64/lib/python2.7/site.py", line 266, in addusersitepackages user_site = getusersitepackages() File "/home/me/python/linux-x86_64/lib/python2.7/site.py", line 241, in getusersitepackages user_base = getuserbase() # this will also set USER_BASE File "/home/me/python/linux-x86_64/lib/python2.7/site.py", line 231, in getuserbase USER_BASE = get_config_var('userbase') File "/home/me/python/linux-x86_64/lib/python2.7/sysconfig.py", line 520, in get_config_var return get_config_vars().get(name) File "/home/me/python/linux-x86_64/lib/python2.7/sysconfig.py", line 472, in get_config_vars _init_posix(_CONFIG_VARS) File "/home/me/python/linux-x86_64/lib/python2.7/sysconfig.py", line 356, in _init_posix from _sysconfigdata import build_time_vars ImportError: No module named _sysconfigdata ERROR: The executable /home/me/cactus/progressiveCactus/python/bin/python is not functioning ERROR: It thinks sys.prefix is u'/home/me/cactus/progressiveCactus/submodules' (should be u'/home/me/cactus/progressiveCactus/python') ERROR: virtualenv is not compatible with this system or executable make[1]: *** [virtPyRule] Error 100 make[1]: Leaving directory/home/me/cactus/progressiveCactus/submodules' make: *\ [all] Error 2

[rsharris]

I recently posted a followup to this-- after correcting my python prefix, I've run into an additional problem.

I'm not sure whether simply posting to the same thread, which had been marked as "closed", is sufficient for someone to be aware of it.

Also, some of the formatting of that latest post got muddled up by auto-formatting. In particular the error log is difficult to read. I'm not sure how to circumvent that.

Bob H

On Sep 9, 2015, at 7:15 PM, Joel Armstrong wrote:

Hi Bob,

Great--glad this worked out OK. Let me know if you have any other trouble.

— Reply to this email directly or view it on GitHub.