I create a new project with the following commands:
mkdir ~/my_project
python -m venv ~/my_project
source ～/my_project/Scripts/activate
pip install flask
pip install kivy
pip install foo
pip install bar
And let's say that I decide to remove my_project and create a new project:
rm -rf ~/my_project
mkdir ~/new_project
python -m venv ~/new_project
source ~/Scripts/activate
Questions:
What happens to previously installed packages "flask", "kivy", "foo", and "bar"? Do I need to re-install them for my new_project's virtual environment?
If I don't need to re-install these packages, then I am missing the point of virtual environment? I thought the whole point of virtual environment is that packages installed in the virtual environment is isolated in that environment. Can someone elaborate?
Indeed, pip installs libraries into a subdirectory of the virtualenv when the env is active. Anything in there is independent of any system-wide installs, and vice versa. Removing the env obviously removes the stuff in the subdirectories.
On the other hand, virtualenv can optionally fall back to system-installed packages if you let it. The system-wide installs will obviously still be there after you remove the virtualenv.
As an aside, the current activate hard-codes some things so that you cannot even rename a virtualenv directory; you have to zap and reinstall it. Keeping all the things it needs in a requirements.txt or similar is a good way to simplify this process, as well as document the dependencies.
The point of Virtual Environment is to separate your development environment from your actual environment. Different projects have different package dependencies. So for these cases Virtual Environment comes in handy.
If you installed flask, kivy, foo, and bar inside a virtual environment, then YES, you need to install them when you move into another Virtual Environment (That's the whole purpose of Virtula Environment).
If you find that the packages are available globally then may be you are not using it correctly. You need to activate your Virtual Environment before you install anything or the packages will be installed globally.
For your case I can see you are activating before installing packages. So it should work right. you can always use pip freeze to see what packages are installed.
Related
I try to install a package with pip in a virtual environement previously created with venv. The Python version is managed through pyenv. I don't want to use pyenv to create the virtual environment.
The project is set up this way. To the project empty directory, I added a .python-version containing the version 3.8.2. Then I created my virtual environement using python -m venv .venv. Then I activated the environement using source .venv/bin/activate. Now the command line starts with a (.env). However, when I try to install some package with pip install some-package, the package ends up in {pyen_home}/versions/3.8.2/lib/python3.8/site-packages, instead of the virtual environment.
What's irritating is that I'm almost certain that I did manage to install package in the virtual environment that way before, but not anymore, so I don't see what I'm missing.
Content of your .python-version should be .venv.
As far as I know you should not create this file by yourself. It generated when you run pyenv local .venv. And venv activates automatically.
Also proper way to create virtual environment is pyenv virtualenv {python-version} {venv-name}. Read the docs carefully.
I'm looking for a way to make a virtualenv which will contain just some libraries (which I chose) of the base python installation.
To be more concrete, I'm trying to import my matplotlib to virtualenv during the creation of virtualenv. It can't be installed efficiently with pip or easy_install since it misses some fortran compiler libs. The way I did it until now was to manually copy from:
/usr/lib/python2.7/dist-packages/ to virtualenv_name/lib/python2.7/dist-packages/
However this prevents the manully imported links to be registerd by yolk (which prints all currently available libs in virtualenv).
So, is there a way to do a selective variant of the
virtualenv --system-site-packages
Create the environment with virtualenv --system-site-packages . Then, activate the virtualenv and when you want things installed in the virtualenv rather than the system python, use pip install --ignore-installed or pip install -I . That way pip will install what you've requested locally even though a system-wide version exists. Your python interpreter will look first in the virtualenv's package directory, so those packages should shadow the global ones.
You can use the --system-site-packages and then "overinstall" the specific stuff for your virtualenv. That way, everything you install into your virtualenv will be taken from there, otherwise it will be taken from your system.
I am late to the game using python.3.8 and pip3 on Ubuntu 20.04.
The ONLY way to get rid of the annoying .local install for me was to set an environment variable (bash):
export PYTHONNOUSERSITE="true"
This does not need to be "true" anything will work. I would not go for a 0. ;-)
Install virtual env with
virtualenv --system-site-packages
and use pip install -U to install matplotlib
I've downloaded a lots of packages into global environment (lets say so). Now, I want to create a new virtual environment and move some of the packages to that environment. How would I do that ?
While you could copy files/directories from the site-packages directory of your global installation into the site-packages of your virtual env, you may experience problems (missing files, binary mismatch, or others). Don't do this if you're new to python packaging mechanisms.
I would advise that you run pip freeze from your global installation to get a list of what you installed, and then store that output as a requirements.txt with your source, and put it under source management. Then run pip install -r requirements.txt after activating your virtualenv, and you'll replicate the dependencies (with the same versions) into your virtualenv.
If you try to copy or rename a virtual environment, you will discover that the copied environment does not work. This is because a virtual environment is closely tied to both the Python it was created with, and the location it was created in. (The “relocatable” option does not work.
However, this is very easy to fix. Instead of moving/copying, just create a new environment in the new location. To create VirtualEnvironment. This way work for me or you can see the link below:
pip install virtualenv
virtualenv NameOfYourVirtualEnvironment
virtualenv NameOfYourVirtualEnvironment/bin/activate
Then, run pip freeze > requirements.txt in the old environment to create a list of packages installed in it which is in your case the global environment. With that, you can just run pip install -r requirements.txt in the new environment to install packages from the saved list. Of course, you can copy requirements.txt between machines. In many cases, it will just work; sometimes, you might need a few modifications to requirements.txt to remove OS-specific stuff.
Source:https://chriswarrick.com/blog/2018/09/04/python-virtual-environments/
And also this may it work for you:
How to import a globally installed package to virtualenv folder
https://gist.github.com/k4ml/4080461
I have my Django project folder and inside that i have my virtualenv folder
I have few questions
I have packages already installed in main installation and as well in virtual env. Dont those packages mix with each other. I mean if i have old version in main installation and new version in virtual env how does the system knows which one to choose
Suppose i move my project folder to new computer than can i use same virtual env folder because it was in the same app directory or i have to start all over again
How will i know that pip install package to virtual env or main installation
Unless you created the virtualenv with --system-site-packages, packages don't mix at all. If they did, Virtualenv has priority.
If the path doesn't change, there are chances that you can reuse it. You could make a virtualenv --relocatable if the path changes. But you should make a requirements file and be able to regenerate a fresh virtualenv in one pip -r req.txt command.
If a virtualenv is activated, pip will install in the virtualenv, it has priority.
I'm looking for a way to make a virtualenv which will contain just some libraries (which I chose) of the base python installation.
To be more concrete, I'm trying to import my matplotlib to virtualenv during the creation of virtualenv. It can't be installed efficiently with pip or easy_install since it misses some fortran compiler libs. The way I did it until now was to manually copy from:
/usr/lib/python2.7/dist-packages/ to virtualenv_name/lib/python2.7/dist-packages/
However this prevents the manully imported links to be registerd by yolk (which prints all currently available libs in virtualenv).
So, is there a way to do a selective variant of the
virtualenv --system-site-packages
Create the environment with virtualenv --system-site-packages . Then, activate the virtualenv and when you want things installed in the virtualenv rather than the system python, use pip install --ignore-installed or pip install -I . That way pip will install what you've requested locally even though a system-wide version exists. Your python interpreter will look first in the virtualenv's package directory, so those packages should shadow the global ones.
You can use the --system-site-packages and then "overinstall" the specific stuff for your virtualenv. That way, everything you install into your virtualenv will be taken from there, otherwise it will be taken from your system.
I am late to the game using python.3.8 and pip3 on Ubuntu 20.04.
The ONLY way to get rid of the annoying .local install for me was to set an environment variable (bash):
export PYTHONNOUSERSITE="true"
This does not need to be "true" anything will work. I would not go for a 0. ;-)
Install virtual env with
virtualenv --system-site-packages
and use pip install -U to install matplotlib