On Mon, May 16, 2016 at 4:28 PM, <redirect.n...@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 -- https://mail.python.org/mailman/listinfo/python-list
