Does conda provide for a way to activate an environment from within a running Python program?
For instance, each virtual environment (venv) created with virtualenv has a script venv/bin/activate_this.py (assuming you are on Linux), that can be used to activate venv within a running Python program as follows:
activate_this = '/full/path/to/venv/bin/activate_this.py'
with open(activate_this) as file_:
exec(file_.read(), dict(__file__=activate_this))
I am just wondering if I need to adapt virtualenv's activate_this.py for this job (virtualenv and conda environments are structured slightly differently, so wouldn't work as is) or there's an existing way.
I think it is not possible the way you intend to. I am not an expert on this field, but the python interpreter of the virtual environment is different. You can also see that the file will only change things of you system path, so that the python interpreter to use will point to the on of the virtual environment. So I think you actually have to spawn a new python process within your script using the python interpreter of the virtual environment. Like this:
import subprocess
subprocess.run(['/full/path/to/venv/bin/python', 'path/to/script.py'])
Related
I'm working on a python CLI project that, unfortunately, is a little complex on the virtual environments side, as it has to deal with multiple ones.
In my quest to get my tool to work properly and robustly, I came across Virtual Env's "activate_this.py" file, which is generated inside the .venv/bin/ directory.
I thought this could be useful for my needs so I started experimenting with it, but I haven't truly understood what it is actually doing under the hood.
For example, it says that the script should be used when a file must be called from an existing python interpreter (which is my case), but the virtual environment must be activated.
What I'm struggling to understand is: What exactly does activating a virtual environment on a given file mean? (Since we're not changing the interpreter)
Also, on the activate_this.py file there's this bit of code:
# add the virtual environments libraries to the host python import mechanism
prev_length = len(sys.path)
for lib in "../lib/python3.9/site-packages".split(os.pathsep):
path = os.path.realpath(os.path.join(bin_dir, lib))
site.addsitedir(path.decode("utf-8") if "" else path)
sys.path[:] = sys.path[prev_length:] + sys.path[0:prev_length]
Does this mean that you can now import libraries that are installed on the virtual env you've just activated, even if they are not installed in the environment of the base interpreter?
You've got it. It rewrites your sys.path to expose the stuff installed in the virtual environment, and it cuts off access to the globally installed third-party libraries not in the virtual environment.
When we want to do anything with our python virtual environment in terminal/command prompt/shell, we have to activate it by navigating to the scripts folder. But, what does this activation do?
I can access the contents of the virtualenv folder in file explorer without activating it.
At its core, the main purpose of Python virtual environments is to create an isolated environment for Python projects. This means that each project can have its own dependencies, regardless of what dependencies every other project has.
More interesting are the activate scripts in the bin directory. These scripts are used to set up your shell to use the environment’s Python executable and its site-packages by default.
After activating the environment, we’re now getting a different path for the python executable because, in an active environment, the $PATH environment variable is slightly modified.
I want to find the Python virtual environments ("venvs" for short) in my file system, and for this I need to know what set of files constitutes a venv.
Some tools - when they want to make sure a directory is a venv - check for the pyvenv.cfg file, but older virtual environments and environments created by Pipenv do not have this file. - Furthermore pyvenv.cfg does not seem to be necessary for activating the venv either.
So what is the minimal set of files to define a working virtual environment? And what is an easy way to check for this in Python?
Clarification:
With "working virtual environment" I mean:
A way to use a specific version of Python executable defined in that environment (and possibly different to the default system Python)
A way to use specific packages (usually installed via pip, bit that's not a requirement).
The Python executable in the venv should be aware of being run inside a venv (see
sys.base_prefix and sys.prefix in the Python documentation.)
Using Python 3.7.0 on Mac. Trying to use venv module that was added post python 3.4.
I setup my virtual env using python3 venv -m path/to/my/dir - my question is do I need to activate this virtual env to use?
The documentation seem to imply I don't need to?
You don’t specifically need to activate an environment; activation just prepends the virtual environment’s binary directory to your path, so that “python” invokes the virtual environment’s Python interpreter and you can run installed scripts without having to use their full path. However, all scripts installed in a virtual environment should be runnable without activating it, and run with the virtual environment’s Python automatically.
If I don't have to activate, what is the benefit of prepending venv to binary directory? Wouldn't this have to happen regardless for a venv to work?
Activating the virtualenv gives you convenience. It is never required.
Even for scripts that are configured to run with #!/usr/bin/env python, (which looks up the python executable on your path), you could manually update the PATH environment variable:
$ PATH="/path/to/venv/bin" some_script
Activating makes the PATH update stick until you deactivate again, and that can be convenient.
For example, I regularly have several virtualenvs in use at any one time. Some of them are there only to install some command-line tools I have symlinked into my ~/bin/ directory, another is home to a Jupyter notebook, and 2 more are used to quickly verify code snippets in different Python versions with access to 3rd-party libraries. I don't activate any of those.
When you don’t activate a virtualenv, all that happens is that your terminal PATH variable is not updated to put the bin directory of the virtualenv first, so when you enter python or pip or other script without any path into the terminal, the shell will find a different Python binary to run. You can always use any of the commands in the virtualenv bin/ directory by giving the full path to that command.
I am trying to set up a virtual environment on my machine, and I am really having trouble.
EDIT: I set up my virtual environment by installing virtualenvironment1.9 and running:
python virtualenv.py -p myVE
Then I add the line
alias goVE='source ~/virtualenv-1.9/myVE/bin/activate'
to my bashrc, and I use goVE to activate the virtual environment. I get a (myVE) at the beginning of the commandline in terminal, so I think it's working. It's just losing the gtk module somehow.
END EDIT
Basically, if I try to
import gtk
in python, it tells me there is no module named gtk. But outside my virtual environment, gtk imports with no problem. I decided it was a problem with the path, so I added
export VIRTUALENV_EXTRA_SEARCH_DIR=$PYTHONPATH
export VIRTUALENV_EXTRA_SEARCH_DIR=/usr/lib64/python2.6/site-packages/gtk-2.0
to my bashrc. Since evidently the gtk module was found in the pythonpath, I thought the first line would do it. When that was insufficient, I tried adding a path specifically to the directory where gtk was located, which I verified by trying
import gtk
gtk.__file__
Since this still didn't work, I tried modifying the virtualenvironment/bin/activate file, so:
PATH = ="$VIRTUAL_ENV/bin:$PATH:/usr/lib64/python2.6/site-packages/gtk-2.0/"
Again, this should be included in the original PATH (unless I'm mistaken), but I'm getting desperate so I tried adding it explicitly to the PATH. For completeness, my PYTHONPATH is set by:
export PYTHONPATH=${PYTHONPATH}:/data/monroe/ebexcode/trunk/GetData/:/home/user1/geach/:/usr/lib64/python2.6/site-packages/
You haven't explained how you created your virtual environment so there's no way to tell if that succeeded. If your virtual environment was created successfully, there's no need to manually munge the paths.
Assuming you have a virtual environment, you haven't demonstrated that you were able to activate it. In order to activate it, you have to run a script in the virtual environment's bin directory. Example, if your virtual environment is in ~/myvenv and you run bash, activate your virtual environment by issuing this at your prompt:
source ~/myvenv/bin/activate
At this point you can use this instance of your shell to install packages into your virtual environment:
pip install PyGTK
Depending on your system installation, this might fail if you do not have all the tools and libraries installed to build the Python GTK bindings.