On Thu, Feb 4, 2016 at 5:50 PM, David A Case <david.case.rutgers.edu> wrote:
> On Thu, Feb 04, 2016, Joseph Baker wrote:
>
> > I looked in the config.h in my amber directory, and I did not see the
> > PYTHON_INSTALL variable in there. The PYTHON path in config.h is
> >
> > #Python interpreter we are using
> > PYTHON=/usr/bin/python2.6
>
> OK: my fault. The PYTHON_INSTALL variable has been added since
> AmberTools15
> was released.
>
> > So I just execute that as root and it runs ./update_amber and the
> > ./configure script and make commands to compile everything. I still had
> to
> > do the manual make_install inside of the MMPBSA directory to get that to
> > update.
>
> This is odd, since I think no one has reported this problem before. There
> is
> a possibility that the Exxact configuration is odd in some subtle way. Or
> there is something else wrong.
>
> Since your problem seems have been fixed (by you), and since the way in
> which
> we handle python will be very different in the upcoming release, I'm
> inclined
> to wait to see if others report the same problem. (Jason may have some
> ideas
> here.)
>
I added something to the Makefile which forces install targets to be
overwritten, but I don't think that's what's happening here. I have a
suspicion and it boils down, perhaps not surprisingly, to "installing as
root". Of course it depends on how you install as root -- are you doing
something like "su -" and running commands as the user root, or using
"sudo" to dispatch commands one by one? It's a very important distinction
(described below). The Makefile in AmberTools 15 has this rule
install: $(BINDIR)/mmpbsa_py_nabnmode$(SFX) $(BINDIR)/mmpbsa_py_energy$(SFX)
$(PYTHON) setup.py install --prefix=$(AMBERHOME)
--install-scripts=$(BINDIR)
I suspect what may be happening here is a misunderstanding of the rocky
relationship between sudo and environment variables. In this Makefile,
BINDIR and SFX are inherited from config.h, but AMBERHOME is inherited from
the environment.
I'll walk through a demo (in bash) and explanation of shell variables,
environment variables, and sudo with the hope that it helps people
understand what may be happening. Let's start with what makes environment
variables special. You can set something as either an environment variable
or a shell variable and access it with the "$" operator. So far, shell and
environment variables look the same:
> export ENVVAR='environment var'
> SHELLVAR='shell var'
> echo $ENVVAR
environment var
> echo $SHELLVAR
shell var
But environment variables are "stickier". If you launch a new shell, that
shell will inherit all of the environment variables of its calling shell,
but none of the shell variables (environment variables have "global" scope
in programming parlance). For example, "bash -c cmd" runs "cmd" in a new
shell and the use of single-quotes here is important [1]:
> bash -c 'echo $SHELLVAR'
> bash -c 'echo $ENVVAR'
environment var
So you see, shell variables do not get inherited by calling shells. But
sudo is special. By default (which is an important security setting), the
environment of the calling shell is NOT passed on to called shells. This
is not entirely obvious -- see this misleading behavior:
>
sudo echo $ENVVAR
environment var
> sudo echo $SHELLVAR
shell var
But ENVVAR and SHELLVAR are expanded from the current shell session. We
need to use the "bash -c" trick to make sure that the sudo command actually
launches another shell. In that case, we can see that the shells we launch
with sudo do not inherit environment variables or shell variables:
>
sudo bash -c 'echo $ENVVAR'
>
sudo bash -c 'echo $SHELLVAR'
You can use "sudo -E" to explicitly inherit the environment:
>
sudo -E bash -c 'echo $SHELLVAR'
>
sudo -E bash -c 'echo $ENVVAR'
environment var
So if you "installed as root" using "sudo" without "sudo -E", then the
MMPBSA.py install line would get interpreted as
/usr/bin/python2.6 setup.py install --prefix=
--install-scripts=/share/apps/amber14/bin
In which case, the modules get installed to /lib/python2.6/site-packages,
and Python never looks there which would fully explain this error. You can
check for the existence of this directory -- if /lib/python2.6 exists, then
it must have been created by the above command (since it doesn't exist in
"standard" CentOS installs).
Which comes back to advice that I give every time I see someone installing
Amber as root: don't do that. If you want to install in a place you don't
have privileges, use root to change the ownership of $AMBERHOME and then
install as a regular user. Our Makefiles could be more robust and avoid
using environment variables (Amber 16 will not have this dependence on
AMBERHOME in the Python Makefiles), but installing/using Amber without
AMBERHOME installed is not supported, nor is the behavior well-defined. If
you do this as root, then anything that would have been a permission error
suddenly "just happens". And some of the clean rules remove files. What
happens if "rm -fr $(AMBERHOME)/bin/*" gets executed as root with AMBERHOME
undefined?... I don't think this could possibly happen in Amber right now,
but I almost never test installing as root so I simply don't know, and
probably can't guarantee that nobody will add something like that in the
future without realizing the potential consequences of running as root.
So maybe it's time to run "sudo chown -R `whoami` /share/apps/amber14" so
you don't have to run any Amber updating/installing as root anymore...
HTH,
Jason
[1] Single-quotes are important to use because double-quotes will tell the
current shell to expand the variable *before* launching the "bash"
program. So the command
> bash -c "echo $SHELLVAR"
will get processed by the shell as
> bash -c "echo shell var"
and the new bash process will happily print the contents of $SHELLVAR,
(mis)leading you to believe that the shell variable is inherited by the
child shell when it's really not. Single quotes prevents this expansion
and sends the string "echo $SHELLVAR" to the new bash process, which is
then responsible for substituting the value of that variable (which is not
defined since shell variables are not inherited).
Whew!
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Feb 04 2016 - 19:30:04 PST
