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.
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 copied a repo containing a Python Django project from my old computer to my new one via git clone. I manage my dependecies in the project via pipenv.
After successfully cloning my repo I wanted to start working on the new computer and tried to select the relevant python interpreter for my project in VS Code . However, the path was not on the list.
So first I tried the command pipenv --venv which gave me the feedback: No virtualenv has been created for this project
So I thought I might need to activate the virtual environment first, before being able to select it in VS Studio code. So i ran pipenv shell in the root directory of my project.
However this seem to have created a new virtual environment: Creating a virtualenv for this project… Pipfile: C:\path\to\my\cloned\project\Pipfile
My questions:
1.) Is this the correct way to activate a pipenv virtualenvironment on a new computer after copying the project via git clone? And if not,...
2.1) Does the way I did it cause any problems, which I should be aware of?
2.2) What would be the correct procedure to activate my virtual enviroment on a new computer?
In general an environment image probably shouldn't be copied to github. You'll get a bunch of unneeded files which clogs your repo.
Instead you should create a requirements.txt from your existing environment pip freeze > requirements.txt and commit that file.
Then when someone else clones your repo they can set up a new virtual environment using any tool they want and run python -m pip install -r requirements.txt
That is, requirements.txt is like a recipe for how to create your environment. By providing the recipe users can use it any way they want.
use:
pipenv install
It worked on Ubuntu, should work also on a mac.
I tried on a windows, it triggered some errors.
"If you download a source repository for a project that uses Pipenv for package management, all you need to do is unpack the contents of the repository into a directory and run pipenv install (no package names needed). Pipenv will read the Pipfile and Pipfile.lock files for the project, create the virtual environment, and install all of the dependencies as needed."
https://www.infoworld.com/article/3561758/how-to-manage-python-projects-with-pipenv.html
I am making a python 3 application (flask based) and for that I created a virtualenv in my development system, installed all packages via pip and my app worked fine.
But when I moved that virtualenv to a different system (python3 installed) and ran my application with the absolute path of my virtualenv python (c:/......./myenv/Scripts/python.exe main.py) then it threw the errors that packages are not installed,
I activated the virtualenv and used pip freeze and there were no packages were installed.
But under virtualenv there is 'Site-Packages' (myenv -> lib -> site-packages) , all my installed packages were persent there.
My Question is how to use the packages that are inside 'site-packages' even after moving the virtualenv to different system in Python 3.
Moving a virtualenv from a computer to another, and even on the same computer from a location to another is a bad idea , and this is why :
Since a lot of the binaries and libs are symlinks, and linked to your old system binaries and libs, it won't work on other machines.
Since many of bin/ scripts in your virtualenv depends on the virtualenv path on the system , it won't work if you moved the virtualenv to another location (even on same system either .)
So the recommend way is :
First generate requirements.txt file :
pip freeze > requirements.txt
Second after moving everything (except the virtualenv directory) create a new virtualenv, activate it and run :
pip install -r requirements.txt
Finally in your case if you really didn't generated a requirements.txt file, and need to use the old site-packages , there is a dirty workaround which i tried once on a gnu/linux machine and somehow worked but am not 100% sure if it will work properly so if you want give it a try.
copy the site-packages in your-old-virtualenv/lib/python{version}/ somewhere in your new computer , Desktop for example
Delete the old virtualenv, and create a new virtualenv
Replace the site-packages in the new virtualenv in new-virtualenv/lib/python{version} with the old site-packages
Delete __pycache__ folder in the newly copied site-packages
Activate the new virtualenv and test if everything is working .
Note that you should use the same python version either 2 or 3 , don't expect a virtualenv that depends on python2 to run properly with python3
Maybe you can consider using pipenv to control the virtualenvs on different computer or environment.
You Must not copy & paste venv, even in the same system.
If you install new package in venv-copied, then it would installed in venv-original. Becaus settings are bound to specific directory.
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 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.