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."
I am in the virtual environment of my Django project.
I ran pip install boto
and it was successful.
I did pip freeze > requirements.txt
, git add requirements.txt
, and git commit -m 'Added boto to requirements.txt'
, all successful.
Then I got into the python shell and imported boto without any resulting errors.
Finally, I ran eb start
on the normal command line again. Same "no module named boto" error.
It seems like the eb start command is not using my virtualenv. What should I do?
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
And then modified the .git/config file to make the aws.push alias call the wrapper
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
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.