The scenario is I have a main virtual environment and I want to implement a functionality where basically user is able to create a new virtual environment extending that main virtual environment (user's environment will be created while main environment is activated ) .
What I mean by extending a virtual environment is that the main environment's packages should be usable in user's environment i.e. there should be no copying and if a user installs a package that already exist in main environment with a different version then this version should get used in user's environment instead of main env's version .
I tried using virtualenv --system-site-packages option and though there were some positive result I landed up in some problem described below .
The main environment also has a base environment and whenever I use virtualenv --system-site-packages option , instead of main env's path , base env's path gets added to the sys.path of user's env .
I'll show 3 attributes of sys path that may help understanding the problem
Main Environment : sys path
sys.real_prefix : A this is base of main env path
sys.base_prefix : B
sys.prefix = B : this is main env's path
User's Environment :
sys.real_prefix : invalid attribute
sys.base_prefix : A this is base of main env's path
sys.prefix = C : this is user env's path
The user's env was created while keeping main env activated . Python Version : 3.5.3
Related
I have this script that creates and activates a virtual environment
import os
import platform
import subprocess
import venv
# Determine the user's platform
current_platform = platform.system()
# Define the name of the virtual environment
venv_name = "my_venv"
# Create the virtual environment using EnvBuilder
builder = venv.EnvBuilder(system_site_packages=False, clear=True, symlinks=False, upgrade=False, with_pip=True)
builder.create(venv_name)
# Activate the virtual environment
if current_platform == "Windows":
activate_path = os.path.join(venv_name, "Scripts", "activate.ps1")
subprocess.call([f"powershell.exe", f"{activate_path}"])
else:
activate_path = os.path.join(venv_name, "bin", "activate")
subprocess.call([f"bash", f"source {activate_path}"])
It works on Windows, however the venv does not remain active when the script finishes executing. This means that I cannot access the venv in the terminal, something which is desirable. If I write ".\my_venv\Scripts\Activate.ps1 " then I see that it is activated. Does anybody have a solution to this?
Executed the script, expected that the venv would remain active in terminal which wasn't the case.
I have a Folder (python311) where I have all of the Python Components stored ("Lib", "Scripts", "python.exe" ...) which is on this Path: D:\python311.
Now I want to move this Folder (python311) into another Folder (Code) -> Path: D:\Code\python311.
Using VS Code it lets me choose the Interpreter which is fine, but when I want to intsll new modules with pip, it does not work. It tries to create an process between the Interpreter of the old Path (D:\python311\python.exe), which is no longer existent, and the new Path where pip is stored (D:\Code\python311\Scripts\pip.exe).
Solutions that I can think of would be for example reinstalling Python. I don't know if it can be solved through environment variables but it won't work because I store the Python Components on an external Drive.
You can solve it using environment variables even if it is on an external drive.
You will need to remove the old entry in the PATH variable and add the new entry (the new python path) or edit the old entry to include the new path.
Change path in environment variables -> Path
Furthermore, I have all my Pythons installed in same location:
PS C:\Python> ls
Directory: C:\Python
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 22.8.2022 11.23 p105_32
d---- 15.8.2022 17.12 p105_64
When I want to use different versions I create a new virtual environment Virtualenvwrapper.
mkvirtualenv envname -p C:/Python/p105_32
workon envname
How can I get system environment variables on Windows? With the below code I only get the user environment variables:
os.environ['PATH']
Or this returns the same:
os.getenv('PATH')
Based on a (deleted) comment I found the solution. System environment variables should be read from the registry if the Python script is run by a user and not by administrator.
import winreg
reg_path = r'SYSTEM\CurrentControlSet\Control\Session Manager\Environment'
reg_key = winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE, reg_path)
system_environment_variables = winreg.QueryValueEx(reg_key, 'Path')[0]
What file do I edit, and how? I created a virtual environment.
The most elegant solution to this problem is here.
Original answer remains, but this is a messy solution:
If you want to change the PYTHONPATH used in a virtualenv, you can add the following line to your virtualenv's bin/activate file:
export PYTHONPATH="/the/path/you/want"
This way, the new PYTHONPATH will be set each time you use this virtualenv.
EDIT: (to answer #RamRachum's comment)
To have it restored to its original value on deactivate, you could add
export OLD_PYTHONPATH="$PYTHONPATH"
before the previously mentioned line, and add the following line to your bin/postdeactivate script.
export PYTHONPATH="$OLD_PYTHONPATH"
The comment by #s29 should be an answer:
One way to add a directory to the virtual environment is to install virtualenvwrapper (which is useful for many things) and then do
mkvirtualenv myenv
workon myenv
add2virtualenv . #for current directory
add2virtualenv ~/my/path
If you want to remove these path edit the file myenvhomedir/lib/python2.7/site-packages/_virtualenv_path_extensions.pth
Documentation on virtualenvwrapper can be found at http://virtualenvwrapper.readthedocs.org/en/latest/
Specific documentation on this feature can be found at
http://virtualenvwrapper.readthedocs.org/en/latest/command_ref.html?highlight=add2virtualenv
You can create a .pth file that contains the directory to search for, and place it in the {venv-root}/lib/{python-version}/site-packages directory. E.g.:
cd $(python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")
echo /some/library/path > some-library.pth
The effect is the same as adding /some/library/path to sys.path, and remain local to the virtualenv setup.
Initialize your virtualenv
cd venv
source bin/activate
Just set or change your python path by entering command following:
export PYTHONPATH='/home/django/srmvenv/lib/python3.4'
for checking python path enter in python:
python
\>\> import sys
\>\> sys.path
I modified my activate script to source the file .virtualenvrc, if it exists in the current directory, and to save/restore PYTHONPATH on activate/deactivate.
You can find the patched activate script here.. It's a drop-in replacement for the activate script created by virtualenv 1.11.6.
Then I added something like this to my .virtualenvrc:
export PYTHONPATH="${PYTHONPATH:+$PYTHONPATH:}/some/library/path"
It's already answered here -> Is my virtual environment (python) causing my PYTHONPATH to break?
UNIX/LINUX
Add "export PYTHONPATH=/usr/local/lib/python2.0" this to ~/.bashrc file and source it by typing "source ~/.bashrc" OR ". ~/.bashrc".
WINDOWS XP
1) Go to the Control panel
2) Double click System
3) Go to the Advanced tab
4) Click on Environment Variables
In the System Variables window, check if you have a variable named PYTHONPATH. If you have one already, check that it points to the right directories. If you don't have one already, click the New button and create it.
PYTHON CODE
Alternatively, you can also do below your code:-
import sys
sys.path.append("/home/me/mypy")
I have a Fabric task that needs to access the settings of my Django project.
On Windows, I'm unable to install Fabric into the project's virtualenv (issues with Paramiko + pycrypto deps). However, I am able to install Fabric in my system-wide site-packages, no problem.
I have installed Django into the project's virtualenv and I am able to use all the "> python manage.py" commands easily when I activate the virtualenv with the "VIRTUALENV\Scripts\activate.bat" script.
I have a fabric tasks file (fabfile.py) in my project that provides tasks for setup, test, deploy, etc. Some of the tasks in my fabfile need to access the settings of my django project through "from django.conf import settings".
Since the only usable Fabric install I have is in my system-wide site-packages, I need to activate the virtualenv within my fabfile so django becomes available. To do this, I use the "activate_this" module of the project's virtualenv in order to have access to the project settings and such. Using "print sys.path" before and after I execute activate_this.py, I can tell the python path changes to point to the virtualenv for the project. However, I still cannot import django.conf.settings.
I have been able to successfully do this on *nix (Ubuntu and CentOS) and in Cygwin. Do you use this setup/workflow on Windows? If so Can you help me figure out why this wont work on Windows or provide any tips and tricks to get around this issue?
Thanks and Cheers.
REF:
http://virtualenv.openplans.org/#id9 | Using Virtualenv without
bin/python
Local development environment:
Python 2.5.4
Virtualenv 1.4.6
Fabric 0.9.0
Pip 0.6.1
Django 1.1.1
Windows XP (SP3)
After some digging, I found out that this is an issue with the activate_this.py script. In it's current state, virtualenv<=1.4.6, this script assumes that the path to the site-packages directory is the same for all platforms. However, the path to the site-packages directory differs between *nix like platforms and Windows.
In this case the activate_this.py script adds the *nix style path:
VIRTUALENV_BASE/lib/python2.5/site-packages/
to the python path instead of the Windows specific path:
VIRTUALENV_BASE\Lib\site-packages\
I have created an issue in the virtualenv issue tracker which outlines the problem and the solution. If you are interested, you may check on the issue here: http://bitbucket.org/ianb/virtualenv/issue/31/windows-activate_this-assumes-nix-path-to-site
Hopefully the fix will be made available in an upcomming release of virtualenv.
If you need a fix for this problem right now, and the virtualenv package has not yet been patched, you may "fix" your own activate_this.py as shown below.
Edit your VIRTUALENV\Scripts\activate_this.py file. Change the line (17 ?):
site_packages = os.path.join(base, 'lib', 'python%s' % sys.version[:3], 'site-packages')
to
if sys.platform == 'win32':
site_packages = os.path.join(base, 'Lib', 'site-packages')
else:
site_packages = os.path.join(base, 'lib', 'python%s' % sys.version[:3], 'site-packages')
With this in place, your activate_this.py script would first check which platform it is running on and then tailor the path to the site-packages directory to fit.
Enjoy!
You will have to execute the activate this, from within the fab file. Altho' I have not tested it, I believe following should work:
activate_this = '/path/to/env/bin/activate_this.py'
execfile(activate_this, dict(__file__=activate_this))