I'm on a mac, and I know that any package I install goes to a specific folder in something like /Library/....
Now when I create a virtual environment, will it create a folder structure to store any libs underneath the virtual environment to isolate things?
e.g.
/home/user/mypythonvirtenv
/home/user/mypythonvirtenv/python2.6/....
Does it re-map the python environmental variables temporarily also?
Yes. Virtualenv will make you a directory tree that looks like:
mypythonvirtualenv/bin
mypythonvirtualenv/include
mypythonvirtualenv/lib
mypythonvirtualenv/lib/python2.6
mypythonvirtualenv/lib/python2.6/site-packages
When you want to use it, you source the activate script:
euclid:~ seth$ which python
/opt/local/bin/python
euclid:~ seth$ source /Users/seth/mypythonvirtualenv/bin/activate
(mypythonvirtualenv)euclid:~ seth$ which python
/Users/seth/mypythonvirtualenv/bin/python
Other python related stuff (such as easy_install) will also work the "right" way.
Related
I need to create new virtual environment in PyCharm. There are already some files in the folder.
This is how my project looks like:
I want to create venv in heureka-negativni-reviews
I try: File -> New project.
I switch this settings:
to have Python 3.10 as an interpreter and to create venv in heureka-negativni-reviews
But when I click on create, I got:
EDIT:
I found that I am not able to select Python 3.10 as an interpreter:
But I cannot click OK when I select Python 3.10:
What is the problem, please?
Now we see the reason, why your IDE is not able to create your venv, since the command line isn't either, which is the set of commands your IDE typically uses.
The pip and pip3 belongs to python3.8 and that is another problem, if you want to install python packages for python 3.10, which isn't possible this time without system invention.
Also your python setup seems to be messed.
/home/vojta/Desktop/INTERNET_HANDEL/HEUREKA/heureka-negativni-reviews/venv/bin/python
seems not to be a general system path. It looks that you built your own version of python and installed it by a specific prefix. Installing python correctly is off the topic here.
There are different installers for different platforms which provide install instruction inside their archives.
Before doing this, it's recommended to clean up your messed installation first.
You may find information here and there.
It could also be, that you are trying to create another venv from within an already sourced venv. Such kind of composed venvs can lead to confusion and that would explain your path above a bit more, which contains /venv/.
Also manually remove all your custom python versions from your /home/vojta/ directory, like $ rm -r /home/vojta/Desktop/INTERNET_HANDEL
First ensure that the Python interpreter is added to the list available (by adding as an 'Existing environment').
Then add a venv via link
Then drag and drop your existing files to the venv directory.
before with venv after drag and drop
I'm a huge beginner so I'm not very informed about how packages really work. I know that you should create a virtualenv in your project folder to avoid version conflicts etc, and you're not supposed to put your actual project files in the virtual env. So if your project files are in your project directory on the same level as the virtualenv, can your project files "access" the things installed in the virtualenv? Can files outside of your directory access packages in your virtual env?
Yes, it all depends on the context. Your virtualenv can exist anywhere, be it in your project directory, or somewhere else.
When you want to use the virtualenv, you just have to call source command on it. Then whatever python command you execute on whichever file, will have access to the virtualenv. For example, if you store your virtualenv in /home/user/project/virtualenv, then you would do
source /home/user/project/virtualenv/bin/activate
Then whatever you with the python, it would be the version installed in virtualenv.
You can double check if you're using the global python or the virtualenv python by doing which python. It will either point to the global python path which is usually under /usr/bin/python or /home/user/project/virtualenv/bin/python.
So normally, you first do the source command, then you can do pip install on whatever packages you need already. It will be installed in the virtualenv and it will not conflict with other projects.
I'm using anaconda for manage my Python's environments and I want to create an env with a python executable file as interpreter. I didn't find similar question on other topic.
To be more precise, I don't want to create an env like this :
conda create --name my_env python=3.6.9
I want to create an env with a pre-installed python interpreter, tell to anaconda where to find the python executable file in my machine (in my case /usr/bin/python3) and use it as the interpreter for the env. Is it possible?
The only way I can imagine accomplishing this would be to make your own build of the python package. Perhaps having a look at how Conda Forge does this might be informative, though you can likely do a very trimmed down version depending on where you expect to run it.
Otherwise, no, not possible, AFAIK.
Should I create a directory in my virtualenv and save the source code for that specific project there?
Thanks in advance
You're not required to have them related in any way. As long as your env is activated, it doesn't matter where it is.
But what's usually easiest is:
Create an empty directory for your project.
Create the virtualenv under that project directory.
Put the source in a src directory under that project directory (or, for really simple projects, just drop it in the project directory).
That way you can check the env settings into version control alongside your code, and if you use an auto-venv tool it'll activate the env every time you cd into the project directory, and so on.
As a side note, if you're just learning this stuff today, you might want to consider learning pipenv instead of using raw virtual environments.
You can save your project anywhere. But you should activate the virtual environment before working on that project.
You can activate the virtual environment using the following command.
source path-to-virtualenvironment/bin/activate
After activating the virtual environment move to your project location.
Why does pip need to use virtual environments to isolate packages per-project, instead of just installing them in a default directory in the project? This seems like added complexity without benefit.
NPM, for example, installs packages in the <project_root>\node_modules by default. No virtual environment necessary, and packages are still installed in a project-independent way.
Edit: To be clear, I'm interested in the practical advantages to pip's use of virtual environments over package management systems like NPM, Nuget, and Webpack, which all use directories in the project. Otherwise, if this is just a limitation of Python's modules system, then I'd be interested to know that too.
Because Python's module system doesn't work that way. If pip were to install, say, requests by just downloading it to a python_modules directory, that wouldn't be enough to for import requests to work; it would have to be import python_modules.requests, but then we'd still have problems whenever requests tried to import one of its dependencies, as that would need python_modules prepended, too, and it'd just be a big mess. The solution that virtual environments use is to modify the PYTHONPATH environment variable to include python_modules, plus some extra stuff to take care of executable scripts and not importing packages from outside the virtualenv.
I think maybe you don't know what a virtual environment actually is.
If you were to put some module in a project-specific directory, like myproj/modules, then you would have to add myproj/modules to the search path that Python uses so that you module can be found. One way to do that is to define or modify the environment variable PYTHONPATH. Any directories listed in that variable will be searched for modules, in addition to some hard-coded set of directories.
$ export PYTHONPATH=./myproj/modules
However, that's really all a virtual environment is. The directory contains the desired version of Python, along with whatever modules you want to use. The activate script you run to "enable" a virtual environment does little more than set the value of PATH and PYTHONPATH so that anytime you run python, both the correct version is used and your project-specific set of modules is used in place of any global library.