As I understand, all that Capistrano does is ssh into the server and execute the commands we want it to (mostly).
I've used rvm in some past couple of projects, and had to install the rvm-capistrano gem. Otherwise, it failed to find the executables (or so I recall), even though we had a proper .rvmrc file (with the correct ruby and the correct gemset) in the repository.
Similarly, today I was setting up deployment for a project for which I'm using pythonbrew, and a simple "cd #{deploy_to}/current && pythonbrew venv use myenv && gunicorn_django -c gunicorn.py" gave me an error message saying "cannot find the executable gunicorn_django". This, I suppose is because the virtualenv was not activated correctly. But didn't we activate the environment when we did "pythonbrew venv use myenv"? The complete command works fine if I ssh into the server and execute it on the shell, but it doesn't when I do it via Capistrano.
My question is - why does Capistrano need modifications to play along with programs like rvm and pythonbrew, even though all it's doing is executing a couple of commands over ssh?
Thats because their ssh'ing in doesn't activate your shell's environment. So it's not picking up the source statements that enable the magic. Just do an rvm use ... before running commands instead of assuming the cd will pick that up automatically. Should be fine then. If you had been using fabric there is the env() context manager that you could use to be sure thats run before each command.
Related
I'm trying to create a virtual environment to deploy a Flask app. However, when I try to create a virtual environment using virtualenv, I get this error:
Using base prefix '//anaconda'
New python executable in /Users/sydney/Desktop/ptproject/venv/bin/python
ERROR: The executable /Users/sydney/Desktop/ptproject/venv/bin/python is not functioning
ERROR: It thinks sys.prefix is '/Users/sydney/Desktop/ptproject' (should be '/Users/sydney/Desktop/ptproject/venv')
ERROR: virtualenv is not compatible with this system or executable
I think that I installed virtualenv using conda. When I use which virtualenv, I get this
//anaconda/bin/virtualenv
Is this an incorrect location for virtualenv? I can't figure out what else the problem would be. I don't understand the error log at all.
It turns out that virtualenv just doesn't work correctly with conda. For example:
https://github.com/conda/conda/issues/1367
(A workaround is proposed at the end of that thread, but it looks like you may be seeing a slightly different error, so maybe it won't work for you.)
Instead of deploying your app with virtualenv, why not just use a proper conda environment? Conda environments are more general (and powerful) than those provided by virtualenv.
For example, to create a new environment with python-2.7 and flask in it:
conda create -n my-new-env flask python=2.7
I have created a python virtual enviornment to runn an applicaton using these instructions:
git clone http://github.com/MediaCrush/MediaCrush && cd MediaCrush
Create a virtual environment
Note: you'll need to use Python 2. If Python 3 is your default python interpreter (python --version), add --python=python2 to the virtualenv command.
virtualenv . --no-site-packages
Activate the virtualenv
source bin/activate
Install pip requirements
pip install -r requirements.txt
Install coffeescript
npm install -g coffee-script
Configure MediaCrush
cp config.ini.sample config.ini
Review config.ini and change any details you like. The default place to store uploaded files is ./storage, which you'll need to create (mkdir storage) and set the storage_folder variable in the config to an absolute path to this folder.
Compile static files
If you make a change to any of the scripts, you will need to run the compile_static.py script.
python compile_static.py
Start the services
You'll want to make sure Redis is running at this point. It's probably best to set it up to run when you boot up the server (systemctl enable redis.service on Arch).
MediaCrush requires the daemon and the website to be running concurently to work correctly. The website is app.py, and the daemon is celery. The daemon is responsible for handling media processing. Run the daemon, then the website:
celery worker -A mediacrush -Q celery,priority
python app.py
This runs the site in debug mode. If you want to run this on a production server, you'll probably want to run it with gunicorn, and probably behind an nginx proxy like we do.
gunicorn -w 4 app:app
I am trying to set this up on a remote server which is hosting 2 other websites.
I haven't actually got it to work properly yet, but what I don't understand is does this
virtual environment have to be running continuously?
If I close my remote connection, or exit the environment does the application cease to function?
And if not how do I exit the virtual environment and continue to work on the server?
The virtual environment isn't something that needs to be running. It's basically a directory where Python libraries and executables can be installed, and a handful of environment variables to ensure that:
new libraries are installed in the virtual environment
When a Python program looks for a library, it looks in the virtual environment
When the system looks for a program to run, it looks in the virtual environment first.
One of the things that happens when you activate the virtual environment is it defines a shell function called deactivate that unsets all the environment variables. So, to get out of the virtual environment, you just type deactivate.
If I close my remote connection, or exit the environment does the application cease to function?
It depends on how you've started your application. If you are just launching it from the command line, then when you close your connection the application will be stopped. Typically you want to use a service like upstart to start and manage your application (the particular service you choose is typically determined by your server's OS). When you configure that service, you'll want to make sure it runs source $your_environment_dir/bin/activate before starting your app, so that your app will run in the virtual environment.
fix: sorry, all is fine, error was because of no module installed in this new environment, jinja2.
First time using virtualenvwrapper so I am little confused.
Setup went fine, I read the docs, but still I don't understand few things.
In my .bashrc file I've set:
# virtualenvwrapper
export WORKON_HOME=$HOME/.virtualenvs
export PROJECT_HOME=$HOME/Snakepit
source /usr/bin/virtualenvwrapper.sh
I already have my project files, so I thougt I should do the following:
Go into ~/Snakepit/ directory, run mkvirtualenv -p /usr/bin/python2 [ envname ]
(I need this specific version for my project), and I saw it created in
~/.virtualenvs/ dir.
My command promt changes showing me that my new environment is [ envname ].
When I do now: python -V, it shows that I am using version 2.7 of python, so
all is well!
But when I move now, my project files into Snakepit directory, and try
running my program with python myprogram.py it shows me errors because it
still tries to run my program with python 3.
How is that possible when python -V shows version 2.7?
Error was not about python version being run, but instead module missing in newly created environment. I will leave it, for a feature reference.
I'm really happy that SourceTree has Mercurial embedded. On the odd occasion I would like to run an hg command from the CLI, like
hg status
To which I get
hg: command not found
Can I make modifications to my environment path to get the command line working for the embedded version, or do I have to install and manage a separate instance of Mercurial if I want to accasionally use the command line?
I'm using SourceTree OS X version 1.7.2
(This might be a superuser question, but I thought this community has a better chance of knowing and responding.)
The binary lies within SourceTree's bundle, in the resources-folder and is called hg_local.
/Applications/SourceTree.app/Contents/Resources/mercurial_local
You might want to alias it somewhere else (like /usr/local/bin) and rename it on the go:
ln -s /Applications/SourceTree.app/Contents/Resources/mercurial_local /usr/local/bin
It might be a better idea to use some package manager and install mercurial from their repositories, eg. Homebrew. This can be done within few minutes and you gain easy access to lots of other command line tools you might want.
# First install homebrew, than run this command
brew install mercurial
I want to build html docs using a virtualenv instead of the native environment on my machine.
I've entered the virtualenv but when I run make html I get errors saying the module can't be imported - I know the errors are due to the module being unavailable in my native environment.
How can I specify which environment should be used when searching for docs (eg the virtualenv)?
The problem is correctly spotted by Mathijs.
$ which sphinx-build
/usr/local/bin/sphinx-build
I solved this issue installing sphinx itself in the virtual environment.
With the environment activated:
$ source /home/migonzalvar/envs/myenvironment/bin/activate
$ pip install sphinx
$ which sphinx-build
/home/migonzalvar/envs/myenvironment/bin/sphinx-build
It seems neat enough.
The problem here is that make html uses the sphinx-build command as a normal shell command, which explicitly specifies which Python interpreter to use in the first line of the file (ie. #!/usr/bin/python). If Python gets invoked in this way, it will not use your virtual environment.
A quick and dirty way around this is by explicitly calling the sphinx-build Python script from an interpreter. In the Makefile, this can be achieved by changing SPHINXBUILD to the following:
SPHINXBUILD = python <absolute_path_to_sphinx-build-file>/sphinx-build
If you do not want to modify your Makefile you can also pass this parameter from the command line, as follows:
make html SPHINXBUILD='python <path_to_sphinx>/sphinx-build'
Now if you execute make build from within your VirtualEnv environment, it should use the Python interpreter from within your environment and you should see Sphinx finding all the goodies it requires.
I am well aware that this is not a neat solution, as a Makefile like this should not assume any specific location for the sphinx-build file, so any suggestions for a more suitable solution are warmly welcomed.
I had the same problem, but I couldn't use the accepted solution because I didn't use the Makefile. I was calling sphinx-build from within a custom python build file. What I really wanted to do was to call sphinx-build with the exact same environment that I was calling my python build script with. Fiddling with paths was too complicated and error prone, so I ended up with what seems to me like an elegant solution, which is to "manually" load the console script entry point and call it:
from pkg_resources import load_entry_point
cmd = load_entry_point('Sphinx', 'console_scripts', 'sphinx-build')
cmd(['sphinx-build', basepath, destpath])