I'm new to virtualenv and not sure how to set up paths. My paths have been set to something like this:
PYTHONPATH=C:\Python27\
PYTHONSTARTUP=C:\Python27\Scripts\startup.py
PATH=%PYTHONPATH%;...;%PYTHONPATH%\Scripts
Should I remove those paths for virtualenv's activate script to work correctly? If I can keep my paths then how do I call scripts for an env when it has been activated? Do I call scripts by explicitly running them with python.exe instead of simply typing the script name alone?
python myscript.py
Not sure how to handle the paths and I would appreciate a little guidance.
First, you have your paths wrong. PYTHONPATH tells Python in what folders to look for Python modules and normally you don't put Python's installation folder in it. For keeping installation folder of Python there's different environment variable called PYTHONHOME. So instead of PYTHONPATH=C:\Python27\ you should have PYTHONHOME=C:\Python27\. You should change PATH variable to use PYTHONHOME accordingly.
As to how to set environment variables when working with virtualenv; you don't need to do anything because virtualenv stores original values when it's activated, modifies environment variables it needs to modify and then restores original values when it's deactivated.
You can take a look at Using Python on Windows
Think you are fine just get on with virtual-env, (follow docs) but remember you must use cmd shell (NO POINT AND CLICKING!!) Took me a while before I realized that...
Once you have activated And installed what you want to in the virtual env,, you invoke scripts by "python scriptname"
Related
I am using windows 7. I have multiple python virtual environments. Say I added venv_1 to system PATH. In the command line, say I activate another venv_2, now the prompt line shows
(venv_2) C:\>
But if I type python here, it still runs the python in venv_1.
Is this the intended behavior?
This is not the intended behaviour, but it probably means you either made a mistake in setting up the virtual environment, or in activating it.
To be sure what version is being run, try running:
where python
Whatever the top item in the resulting list is, will be the copy of Python Windows would start. If you're right and it does actually point to venv_1, then there must be something wrong with the setup in venv_2.
By running set, you should be able to see a list of all environment variables. Check for:
PATH=<long list of directory names, it should have the venv_2\Scripts at the start>
And:
_OLD_VIRTUAL_PATH=<the same list, without that entry>
It's this simple change to the path that causes Windows to find the Python in your virtual environment first, before the one in your other virtual environment, that you added to the global path.
Note that adding the Scripts folder of the one virtual environment probably isn't a good idea, since you'd only want to use that when the corresponding virtual environment is activated and all the environment variables set accordingly.
Created virtual environment in ~/python/venv/venv_python2 folder.
I can run python in a regular way (for venvs):
source ~/python/venv/venv_python2/bin/activate
python
or I can run python with:
~/python/venv/venv_python2/bin/python
What is a difference between 2 above?
There is no difference.
You can check where python is running from by typing which python in bash. You'll see that it points to your virtual env when you're in it.
The purpose of the virtual environment is to isolate the dependencies inside it so you don't have to worry about knowing the precise path to the correct Python interpreter or the libraries you have installed. So while using the absolute path is technically not incorrect, it completely bypasses the facilities of the virtualenv, and could eventually end up pointing to the wrong location if you hardcode it in a script today, and decide to move, migrate, or refactor your virtualenv tomorrow.
There is a very slight, almost irrelevant difference between the two:
~/python/venv/venv_python2/bin/python specifies exactly which Python interpreter you want to use.
python runs which ever interpreter is found first when examining your path.
One of the things that source ~/python/venv/venv_python2/bin/activate does is that it puts ~/python/venv/venv_python2/bin at the front of your path, so that when you run /-free command, the first place the shell looks is that directory, meaning python will resolve to the one in your virtual environment.
So, the only way your two ways would differ is if something else modified your PATH in the meantime.
I have a full python installation with files in /usr/local/, but also have one that I compiled from source sitting in ~/python_dist. If I look at sys.path on each interpreter I see that they indeed import from different libraries.
Currently I can run $ PYTHONPATH=~/other_py_libs ~/python_dist/bin/python to invoke the custom interpreter with some other modules available in the path. However, I don't want permanently change the global PYTHONPATH variable.
How can I permanently change the python path for only one specific python install?
The easiest way to do this is to use a virtualenv (manage with virtualenvwrapper). With virtual environments you can set up different, isolated python environments (kind of like little python playgrounds). Switching between them (with the help of virtualenvwrapper) is as easy as typing workon envname. You don't have to worry about switching the PYTHONPATH around, and you can direct scripts to use a specific environment simply by running them with the python install in that environment, e.g. using #! /home/myname/.virtualenvs/envname/bin python.
I have a virtualenv in a structure like this:
venv/
src/
project_files
I want to run a makefile (which calls out to Python) in the project_files, but I want to run it from a virtual environment. Because of the way my deployment orchestration works, I can't simply do a source venv/bin/activate.
Instead, I've tried to export PYTHONPATH={project_path}/venv/bin/python2.7. When I try to run the makefile, however, the python scripts aren't finding the dependencies installed in the virtualenv. Am I missing something obvious?
The PYTHONPATH environmenbt variable is not used to select the path of the Python executable - which executable is selected depends, as in all other cases, on the shell's PATH environment variable. PYTHONPATH is used to augment the search list of directories (sys.path in Python) in which Python will look for modules to satisfy imports.
Since the interpreter puts certain directories on sys.path before it actions PYTHONPATH precisely to ensure that replacement modules with standard names do not shadow the standard library names. So any standard library module will be imported from the library associated with the interpreter it was installed with (unless you do some manual furkling, which I wouldn't recommend).
venv/bin/activate does a lot of stuff that needs to be handled in the calling shell's namespace, which can make tailoring code rather difficult if you can't find a way to source the script..
You can actually just call the Python interpreter in your virtual environment. So, in your Makefile, instead of calling python, call venv/bin/python.
To run a command in a virtualenv, you could use vex utility:
$ vex venv make
You could also check, whether make PYTHON=venv/bin/python would be enough in your case.
PYTHONPATH adjusts sys.path list. It doesn't change python binary. Don't use it here.
Is it possible to specify site directories through python command line or environment?
Right now I'm using site.addsitedir, but I would like to make the script agnostic of the site-setting logic
The PYTHONPATH environment variable is essentially the same thing. Set it to a directory containing Python modules or packages and it will be added to sys.path at initialization.