Virtualenv and CLI tools
I know how to use virtualenv to isolate Python dependencies in a long running script like Flask or Twisted. But I was puzzled as to how you should do this for a script to be called from the command line.
Let's say I wanted to create a CLI tool to interact with some API, perhaps with Click or docopt. Obviously, you don't want to have it source venv/bin/activate
every time you want to use this tool. But I would suggest it is still better to use virtualenv to keep your environment clean even after development.
Sorry for the newbie question, but ... what should you do to package the script so that it can be used in this way? (I'm more used to RubyGems, and still see Pip and VirtualEnv.)
source to share
In general, if a package that you installed in a virtual env environment that provides a binary command line script, say, ~/.virtualenv/bin/
you can paste it in ~/bin/
(or anywhere on your path where you would like to put local scripts).
There are a couple of projects that address this problem:
source to share
An excellent article on virtualenv from Dabapps will give you an idea: http://www.dabapps.com/blog/introduction-to-pip-and-virtualenv-python/
How to call it from a CLI script:
1. cd for your project root
2.env / bin / python your_main_file.py (Assuming your virtualenv is called env)
This way you don't have to run virtualenv every time.
source to share
Each virtualenv has its own Python site_packages, built-in modules, and a Python interpreter. Thus, virtualenv is intended to be used at the project level , not at the package-by-package level. It isolates a collection of Python modules and possible dependencies. Each virtualenv has its own location where pip will install packages. In theory, virtualenv shouldn't be necessary, but in practice it's nice to have a way to have different "environments" with different versions of Python modules and Python interpreters. I don't know if Ruby has something like this, which will allow you to have different "sets" of gems for different projects.
People who use direct virtualenv will add aliases to theirs .bashrc
, for example:
alias workonawesomeproject="source ~/venv/awesomeproject/bin/activate"
They activated virtualenv with an alias
workonawesomeproject
To exit virtualenv you use the command deactivate
An easier way to deal with virtualenvs is to use virtualenvwrapper
pip install virtualenvwrapper
Add these lines to your .bashrc
(or other shell init file)
export WORKON_HOME=$HOME/venv # this directory is your choice
export PROJECT_HOME=$HOME/src # this directory is your choice
source /usr/local/bin/virtualenvwrapper.sh # leave this alone
If you just changed yours .bashrc
, be sure to submit it
source ~/.bashrc
Then, to create a new virtualenv, you simply run
mkvirtualenv awesomeproject
To use this virtualenv
workon awesomeproject
To disable this virtualenv
deactivate
Virtualenvwrapper Docs: http://virtualenvwrapper.readthedocs.org/en/latest/install.html
source to share