How to create development Python environment on Linux.

[Zachary Ware]

On Mon, May 16, 2016 at 4:28 PM,  <redirect.null at gmail.com> wrote:
> Thanks Zach, that's a big help. The only reason I want to get a Python 2.7 environment working first is because I'll be working on third party code and that's the platform it uses. For any new projects I would use Python 3.

Fair enough :)

> After considering your guidance I think what I will do is install virtualenv using apt-get and then use that to create a dev environment. Is it ok to run get-pip.py in a virtual environment?

Sounds like a plan.  get-pip.py should work fine in a venv, but first
check to see if pip is already there, as Michael mentioned.

> I won't worry about using the latest version of 2.7 for now, since it's only one or two third party open source projects I'll use 2.7 for and they don't need a more recent version.
>
> There are a couple of other things I'm not quite clear on, such as where it would be best to create my new virtual environment (I'm tempted to put it in /usr/local if that means it can be used by all user accounts on my machine), and how I can can control which Python environment is used by the various system and user programs that depend on them, but I expect I can find that information on the web, though I'll make another post here if I do get stuck.

The thing about virtual environments is that you can create as many as
you want wherever you want, and they're all independent of each other.
All you need to do is have a way to consistently recreate the same
environment, which is usually easiest to do with a 'requirements.txt'
file with all of your dependencies' versions pinned.  Then recreating
the venv is as simple as `virtualenv --python=some_python
/path/to/venv && /path/to/venv/bin/pip install -r
/path/to/requirements.txt`.  Then you can do your development wherever
you want and install into somewhere in `/usr/local` when you deploy.
For example, one project I work on creates a venv in
`/usr/local/lib/project_name/`, then creates links to the entry point
scripts (that actually live in `/usr/local/lib/project_name/bin/`) in
`/usr/local/bin/`.

As for controlling which environment is used: all system scripts/apps
should specify some version-specific flavor of /usr/bin/python in
their shebang--if they don't it's an OS bug and should be filed as
such.  For your stuff, the path of least headache is probably to
create a venv for each one, and specify the path to the venv's python
in shebang lines.

Hope this helps,
-- 
Zach