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.
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
Is there a way to specify the location of the virtualenv executable for tox to use?
Here is the problem:
The company I work for uses its own patched python with its own virtualenv. That virtualenv executable is very old, and it cannot be used to install the dependencies needed for the project, so when the project is initialized and the virtual environment for that project is created, the virtualenv executable in that environment gets updated to a later version. When I activate that environment and try to run tox in it, tox uses that environment's virtualenv executable to create its own (that is, tox's) virtual environments. However, that updated virtualenv executable cannot create a correctly configured virtual environment for that patched python. To do that, I need to be able to call the initial 'old' patched virtualenv executable, and thus I need to be able to tell tox where to look for it.
Hope this explanation is not too convoluted.
Your only real option is to create a tox plugin that uses the patched virtualenv - see https://github.com/tox-dev/tox/blob/master/src/tox/venv.py#L698 and https://tox.readthedocs.io/en/latest/plugins.html#creating-a-plugin
I am trying to create a new python 3.7 virtual environment on my local computer running Windows 8. I have python versions 3.6, 3.7, and 3.8 installed. Their exe's are named python36, python37, and python, respectively. All three are correctly added to PATH because I can enter each interpreter.
Within my new project's directory I tried to create a virtual environment with python37 -m venv env. It produced an error: Error: [WinError 2] The system cannot find the file specified, but it still created the directory. However the Scripts subfolder is empty except for pythonw.exe.
In this question someone suggests doing python37 -m venv env --without-pip. When I tried this, the activation/deactivation scripts were created, but the virtual environment is using python 3.8.
It is my understanding that venv will create the virtual environment with what ever python exe you use to call it, so I don't understand how this can happen. I've verified that python37 points to the correct place with where python37, and can even enter the 3.7 interactive interpreter.
The problem was that I renamed the python exe's. I don't know exactly what goes wrong, but presumably at some point venv tries to find python.exe and is thrown off by the name.
Changing them back to python.exe and differentiating between the versions with their location fixed the problem.
Edit:
Check out Eryk's comments for more details.
First create folder at any drive then go to that folder and install virtualenv package using pip.
pip install virtualenv
Then create your virtual environment.
mkvirtualenv myvirtualenv
Then use below command to activate virtualenv in windows.
myvirtualenv\Scripts\activate
After this you can install related package in current virtual environment.
The Python Standard Library for Creating Virtual Environment
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.
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.