I have a python installation with several packages linked to it that I access by calling python2.7. I would like to create a virtual env where I can just type python and access that particular installation without reinstalling everything associated with it. How would I accomplish that (virtual env, symlink, etc...) without changing my default env?
virtualenv allows to specify the Python executable you want to use with the --python (or -p) option, e.g.:
virtualenv --python=/usr/bin/python2.7 path/to/env
You can also use --system-site-packages to include the packages that are installed globally.
Related
I use Python and pip trhough the asdf version manager, and in my older PC, when I create a new venv it already came with some default packages. I'm now using a newer verison of python (3.9.12) and pip (22.0.4), and it does not come with basic and essential things, such as the gnureadline, to be able to see the commands history in the python's shell. It's really annoying having to install it again in all new venvs and I'm trying to avoid an alias to create a venv and install what I want inside it. There is a way to set some default packages to all venvs?
There is an option:
--system-site-packages
Give the virtual environment access to the system
site-packages dir.
So if you use python3 -m venv --system-site-packages .venv then you may install the packages you want available to all envs at the system level. You'll have to be hygienic about the packages installed at the system level.
If the system python on your distribution is a hot mess, and you can't remove things you don't want visible in venvs from it, then you'll want to look for another option.
One possibility is just to install common packages to some target directory:
python3 -m pip install dep1 dep2 --target=/path/to/common
And then make this directory of packages always visible:
export PYTHONPATH=/path/to/common
Running command line:
virtualenv --system-site-packages venv
I'm expecting venv folder venv\Lib\site-packages to contain all the necessary library from the projects that are located in:
C:\Users\XXX\AppData\Local\Programs\Python\Python36\Lib\site-packages\
But it's not the case, only a few are installed.
Example, my program currently use pdfminer which is in
C:\Users\XXXX\AppData\Local\Programs\Python\Python36\Lib\site-packages\
I want it to be included in venv\Lib\site-packages but it is not copied.
Any advice?
--system-site-packages doesn't copy packages, it just allows python from the virtualenv to access packages in C:\Users\XXX\AppData\Local\Programs\Python\Python36\Lib\site-packages\.
There is no way to copy packages because they could depend on their installation directory. If you want these packages in the virtualenv don't use --system-site-packages and install all packages in the virtualenv.
A virtualenv environment is the same as if you have just installed a new version of Python. It has no packages other than the standard packages provided with Python. If you want other packages, you have to install them with 'pip' or however you'd do it with the native Python version that you are using.
So in general, just do pip install <packagename>.
If you find yourself often wanting to create virtualenvs with a standard set of base packages, then put together a requirements.txt file listing all of the packages you want to install as a base, and do pip install -r requirements.txt inside a new virtualenv, right after you create it.
One nice thing about a virtualenv is that it's all yours. Your user owns 100% of it, unlike the base Python version that is owned by the system. To install new packages into the base Python version, you often have to have root access (sudo privileges). With virtualenvs, you don't need special permissions (in fact, you'll get all screwed up if you use sudo in a virtualenv) to install all the packages you want. Everything you do lives within your own home directory. Another neat thing is that when you are done with a virtualenv, you just throw away the root directory that contains it.
If its not mandatory to use virtualenv, I would suggest to go with Anaconda. That'll pretty much help your concern.
Conda as a package manager helps you find and install packages. By default quite a few packages are already installed, so as to set you up quickly for your project. To check the list of packages installed in terminal, type: conda list to obtain the packages installed using conda.
If you need a package that requires a different version of Python, you do not need to switch to a different environment manager, because conda is also an environment manager.
With just a few commands, you can set up a totally separate environment to run that different version of Python, while continuing to run your usual version of Python in your normal environment
We have an application which does some of its work in Python in a python virtual environment setup using virtualenv.
We've hit a problem where the version of a system library does not match the version installed in the virtual environment. That is we have NetCDF4 installed into the virtual environment and and previously had libnetcdf.so.7 installed through yum. The python package appears to be dependent on having libnetcdf.so.7 available.
Due to a system update libnetcdf.so.7 no longer exists and has been replaced by libnetcdf.so.11.
So the question is this: Does setting up the virtual environment detect the system library version or is there some other mechanism? Also do we need to re-build the environment to fix this or is there another option?
When you use virtualenv to create a virtual environment you have the option of whether or not to include the standard site packages as part of the environment. Since this is now default behaviour (though it can be asserted by using --no-site-packages in the command line) it's possible that you are using an older version of virtualenv that doesn't insist on this.
In that case you should be able to re-create the environment fairly easily. First of all capture the currently-installed packages in the existing environment with the commmand
pip freeze > /tmp/requirements.txt
Then delete the virtual environment, and re-create it with the following commands:
virtualenv --no-site-packages envname
source envname/bin/activate
pip install -r /tmp/requirements.txt
However none of this addresses the tricky issue of not having the required support libraries installed. You might try creating a symbolic link to the new library from the old library's position - it may be thatNetCDF4 can work with multiple versions of libnetCDF and is simply badly configured to use a specific version. If not then solving thsi issue might turn out to be long and painful.
I'm using Python 3.4 on Windows.
I have created a virtual environment with
python c:\Python34\Tools\Scripts\pyvenv.py foo
Then activated it
foo\Scripts\activate.bat
And installed several libraries in it.
Question: Is it safe to rename the venv folder "foo" to "bar"?
I.e. once i have renamed foo to bar, then activate it with
bar\Scripts\activate.bat
will it still work?
What could make problems are any environment variable settings and absolute paths.
To be able to do that you should use virtualenv. From the docs:
Normally environments are tied to a specific path. That means that you cannot move an environment around or copy it to another computer. You can fix up an environment to make it relocatable with the command:
$ virtualenv --relocatable ENV
This will make some of the files created by setuptools or distribute use relative paths, and will change all the scripts to use activate_this.py instead of using the location of the Python interpreter to select the environment.
Note: you must run this after you've installed any packages into the environment. If you make an environment relocatable, then install a new package, you must run virtualenv --relocatable again.
But be aware:
The --relocatable option currently has a number of issues, and is not guaranteed to work in all circumstances. It is possible that the option will be deprecated in a future version of virtualenv.
Is there a way to activate a newly created virtualenv within an Ant script such that any calls to <exec executable="python"> (site-packages lookups etc) uses the virtualenv and not the global shared path?
I should note that a solution must work on Windows, Linux and Mac.
You can refer directly to the executable in the virtualenv:
<exec executable="<virtual_env_dir>/bin/python">
...
This will automatically use the packages installed in the virtualenv rather than those in the base install.