AWS's Elastic Beanstalk not using my virtualenv: “No module named boto”

Question

I\'m trying to use AWS\'s Elastic Beanstalk, but when I run eb start, I get \"ImportError: No module named boto Cannot run aws.push for local repository HEAD.\"

Answer 1

I had a similar problem using eb push. The issue is that eb uses git during the process to push the contents to AWS (git aws.push). You can find the scripts inside ".git/AWSDevTools/" on your repository dir.

When git runs it modifies the environment variable $PATH and appends "/usr/libexec/git-core:/usr/bin" to the beginning of $PATH. This makes the AWS scripts to use /usr/bin/python instead of the python on the virtualenv, which doesn't have boto installed.

I fixed this by adding a wrapper on top of the AWS scripts that verifies if there is a virtualenv enabled and corrects the $PATH variable.

.git/AWSDevTools/pre.aws.elasticbeanstalk.push

#!/bin/bash

if [ -n $VIRTUAL_ENV ]; then
    PATH=$VIRTUAL_ENV/bin:$PATH
fi

DIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )
python $DIR/aws.elasticbeanstalk.push

And then modified the .git/config file to make the aws.push alias call the wrapper

[alias "pre.aws.elasticbeanstalk"]  
    push = !.git/AWSDevTools/pre.aws.elasticbeanstalk.push

[alias "aws"]
    push = !git pre.aws.elasticbeanstalk.push  #Modified this line to call the wrapper

Answer 2

OK, this is a hack, and an ugly one, but it worked.

Now, the error is happening on the local machine, nothing to do with remote.

I have boto installed locally and I am NOT using virtualenv (for reasons of my own, to test a more barebones approach).

1 note where the error is happening - in .git/AWSDevTools/aws/dev_tools.py

2 run a non-virtualenv python and

import boto print boto.file /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/boto/init.pyc

3 open up that dev_tools.py and add this on top:

import sys sys.path.append("/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages")

Since you are appending to sys.path, you will only import modules from that addition if git aws.push hasn't found it in its own stuff.

That fixes the problem for now, except that it will re-occur on the next directory where you do an "eb init"

4 Go to where you have unzipped the CLI. In my case:

$cd ~/bin/AWS-ElasticBeanstalk-CLI-2.6.1

now

5 look for the original of dev_tools.py used by eb init

$find ~/bin -name dev_tools.py ~/bin/AWS-ElasticBeanstalk-CLI-2.6.1/AWSDevTools/Linux/scripts/aws/dev_tools.py

edit this file as in #3

if you do another eb init elsewhere you will see that your ugly hack is there as well.

Not great, but it works.

p.s. sorry for the formatting, newbie here, it's late and I wanna go skating.