[TriLUG] arguments to remove a thin python wrapper

[Igor Partola]

No problem on the RTFM. I am not a huge fan of Virtualenv, as I think it's
a bandaid to the bigger problem (no proper and correct package management
for Python). However, it is the industry standard. Unless you are writing
distro code, you are likely to be using (or should be using Virtualenv).

To actually set it up, you can typically put an executable into /usr/bin/
and at the top of it put something like:

    #!/var/lib/virtualenvs/my-virtual-env/bin/python

Now that file will execute the virtualenv's Python interpreter (which can
be a symlink to the system one or a new version you compiled yourself and
installed into my-virtual-env). This way the user needs no knowledge of
which particular interpreter they are using. Of course by calling the
my-virtual-env Python interpreter it would have access to all the extra
libraries you may have installed into my-virtual-env which you might not
have available to the whole system.

Another way to do this is to "activate" the env. Normally
/var/lib/virtualenvs/my-virtual-env/bin is not a part of your $PATH, but
activating the env will place it there:

   $ source /var/lib/virtualenvs/my-virtual-env/bin/activate
   (my-virtual-env) $ foo

Where foo is the executable inside /var/lib/virtualenvs/my-virtual-env/bin/
but not system-wide. If the top of
/var/lib/virtualenvs/my-virtual-env/bin/foo has

    #!/usr/bin/env python

It will be resolved to /var/lib/virtualenvs/my-virtual-env/bin/python and
all will be well.

A third way is to use Virtualenv Wrapper (
http://virtualenvwrapper.readthedocs.org/en/latest/), which basically lets
you set a standard location of where your virtual env's live and gives you
a shortcut for activating them. This is indispensable to developers who
work with Python: install this on your workstation and run bash/zsh/etc
interactively. This isn't going to help your deployments but will save many
keystrokes when activating random env's. You can even get it to run
arbitrary commands pre and post activation and de-activation. For example,
all my code lives in $HOME/projects/, such as $HOME/projects/foo. Now when
I run `activate foo`, not only is the virtual env activated, but it will
actually cd to $HOME/projects/foo/ as well.

Igor