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.
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.
I have found a partial answer in this question:
Adding Anaconda to Path or not
But I still don't fully understand. I have had a lot of installation issues when switching from a normal installation Python to Anaconda, requiring me to completely re-install Windows... So i want to get this right now.
What happens internally when I Add Anaconda (or python for that matter) to the PATH? I plan on working with seperate conda environments for different python versions, what could go wrong if I add Anaconda to path in the installation? And what is the difference between doing it in the installation or doing it later through the command prompt? Will it affect my ability to integrate anaconda with PyCharm?
PATH is an environment variable that is a list of locations where executable programs lie (see also the wikipedia page.
Whenever you are in your command line and try to execute some program, for example regedit, then the cmd does not magically know that you mean C:\Windows\regedit.exe. Instead, it searches all locations in your PATH for an executable named regedit and finds it in C:\Windows which is one of the standard parts of PATH in Windows.
That is also, why messing with the PATH can be dangerous if you don't know what you are doing, because it might lead to things not working anymore if, for example you delete parts of the path or add custom directories to it.
That being said, you should now have an idea what happens when you "Add anaconda to path". It simply means, that Anaconda adds the directory where its executables lie to the PATH, hence making it findable when, for example you type conda in your cmd.
That being said, adding Anaconda to PATH is something that is convenient, because the commands can always be found automatically and they will also be found by other programs scanning your PATH for a python executable.
At the same time it is not necessary. When you use e.g. pycharm, then you can specify the path to the interpreter inside of pycharm. it does not necessarily need to be present in your PATH.
Note:
I personally have it on my PATH because I am too lazy to open an Anaconda prompt each time I need it in a cmd and I do not see the harm in it if you understand the consequences and its my only python installation anyway.
Also Helpful:
On windows, you can use the where command to find out from where commands are loaded. For example:
where regedit
gives
C:\Windows\regedit.exe
This can be especially helpful when trying to debug PATH issues
The python.exe of the base environment resides in the
C:\Users\USERNAME\AppData\Local\Anaconda3 folder
If you add this folder to the PATH, you can call that version directly from the prompt and Python will also find many of the installed packages via that anchor folder. However, this is not true for e.g. the Numpy package which heavily depends on compiled C libraries. So you would also need to add the following folders to the PATH:
C:\Users\USERNAME\AppData\Local\Anaconda3\Library\mingw-w64\bin;
C:\Users\USERNAME\AppData\Local\Anaconda3\Library\usr\bin;
C:\Users\USERNAME\AppData\Local\Anaconda3\Library\bin;
C:\Users\USERNAME\AppData\Local\Anaconda3\Scripts;
C:\Users\USERNAME\AppData\Local\Anaconda3\bin;
This is exctly what the activation is for, plus it also gives you the option to easily switch between environments.
Bottom line: Adding Anaconda to the PATH might help in simple cases, but the whole concept of Anaconda's dependency management depends on environments and their activation. It's better to use Anacona the proper way right from the beginning and NOT to add Anaconda to the PATH.
What I want to do is to create a GUI for my tensorflow program.
However, I can't seem to run my conda tensorflow environment inside my python script.
I have already tried this code
subprocess.call("activate tensorflow", shell=True)
but it still says that it cant find the tensorflow module.
Not in general. A virtualenv has its own copy of the Python interpreter, possibly with a different version than the system-wide (most problematically, one can be Python 2 and the other Python 3). Once you have already started one Python interpreter you cannot hot-swap it with another.
If you know that both versions of the interpreter are the same, then you could try something like adding the virtualenv lib and site-packages directories at the beginning of sys.path before doing anything else, but that's not really clean and even then some things may not work correctly (besides, I think the default virtualenv and the Anaconda virtualenv directory structures are somewhat different). Also, even if this worked, it would definitely not be possible to dance around from one virtualenv to another after you start importing modules (once you import a module, there is no way to "unimport" it, and every future reference will use the one loaded first, no matter what sys.path says).
It would be better to just have a different process to work in the virtualenv. You can run a second interpreter directly from the first one, or call a batch/shell script to do it for you, or replace the first Python script with a batch/shell script, etc.
I am trying to run script in bash from python, but I am currently working in a virtualenv, and when my script calls on a specific program, I get "usr/bin/env: luajit: No such file or directory".
When I run the same script inside a separate bash window (outside the virtualenv), it runs perfectly.
I have a feeling it is because this program is not properly being pointed to, but have no idea how to tell my virtualenv to look for that program.. How do I get around this?
I am on Ubuntu 14.04, using python 2
The answer lies in environment variables. PATH should contain the location where your luajit is.
See setting an environment variable in virtualenv for some ways to automatically set environment variables in a virtualenv (but two of the currently suggested ways require wrappers and one - editing a stock script). There's no magic: virtualenv edition by Allison Kaptur describes the (rather simple) magic behind virtualenv's work so you may be able to find an even better place to put the variable assignment in.
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"