I have an old computer with dozens of old python projects installed, each with its own different virtualenv, and many of which built with different versions of python.
I'd prefer not to have to download these different versions when I create new virtualenvs via virtualenv -p whatever path that version of python has
My question is: within a virtualenv, is there a command I can run to find the path to the version of python which was used to create that particular environment?
For example, if I created a venv with 'virtualenv -p /usr/bin/python3.4' and then ran this command with the venv activated, it would return '/usr/bin/python3.4'
Since virtualenv copies python completely (including the binary) there is no way to know the exact path it originated from.
However, you can easily find the version by running ./python --version inside the environment's bin folder.
You could try running something like this from the command line:
python -c "import sysconfig; print(sysconfig.get_config_var('BINDIR'))"
Related
I am trying to use Python3 with PyCharm.
So I installed Python(3.10.1) and PyCharm(2021.3.1)
But when I try to create a new project, PyCharm want me to choose 'base interpreter'
and I don't know which one to choose.
Here is the list of base interpreter:
I want to know what is difference between /usr/bin/python3 and Library/Frameworks/Python.framework/Versions/3.10/bin/python3
Usually the files under /usr/bin/ are symlinks to actual files, which means they are not real files but links to the actual file.
To see it for yourself go to the /usr/bin/ directory with a terminal and execute:
ls -a
I suppose macOS already ships with python and by installing Python 3.10 you added that last element to the list, which is also linked by /bin/usr/python3.
I'd go with /usr/bin/python3, more portable.
You can choose the one interpreter for the version of python you want. In your terminal, you can run python --version or python3 --version and it will display the version of python, Like this:
$ python --version
Python 2.7.16
$ python3 --version
Python 3.9.1
Performing which python, will give you the path to that python binary, like the following (although, this is where we are leaving "Python" and talking more about the OS and PATH.
$ which python3
/usr/local/bin/python3
For the other versions of Python you have installed, you can check their version by doing something like:
/Library/Frameworks/Python.framework/Versions/3.10/bin/python3 --version
You'll find that you may choose different versions of python for different projects. In the future, you may consider using venv to setup virtual python environments per project.
If you're just getting started with Python, I'd suggest sticking with the version you installed 3.10.1, and choosing that interpreter.
The base interpreter is the python.exe file that will run everything you do inside that project.
I would suggest you use Anaconda as a package manager and then create a virtual environment with the version of Python you need. Just follow these steps:
Getting started with Anaconda: https://docs.anaconda.com/anaconda/user-guide/tasks/pycharm/
Choosing an Anaconda virtual environment with Pycharm:
https://docs.anaconda.com/anaconda/user-guide/tasks/pycharm/
A package manager like Anaconda is very useful when working with Python.
Otherwise:
In your list you have many different versions of python. You should choose the base interpreter based on the python version you want to use.
Always select the latest version.
Since I use Python 3.9, it will be:
/usr/local/bin/python3.9
Based on your image, it would be:
/usr/local/bin/python3
The interpreter is what version your PyCharm project uses. It appears you have python2 and python3, so if you were writing in python2, you would use the python2 interpreter.
I would select the latest version, which in your case would be:
/usr/local/bin/python3
I am an absolute beginner with Python (I came from Java) and I have the following doubt about the venv folder in my project.
So basically I have this project structure:
As you can see it contains the venv folder. Reading on the Python official documentation:
https://docs.python.org/3/library/venv.html
I can read:
The venv module provides support for creating lightweight “virtual
environments” with their own site directories, optionally isolated
from system site directories. Each virtual environment has its own
Python binary (which matches the version of the binary that was used
to create this environment) and can have its own independent set of
installed Python packages in its site directories.
So from what I can understand it means that, using venv, every project have its own venv folder containing:
The bin folder: it contains the Python interpreter binary (in this specific case Python 3.7).
The lib folder: containing the dependencies that I have installed using pip3 (infact I installed scapy and scapy_http via pip3)
This because my PyCharm IDE is set to use Python 3.7
If this reasoning is correct (I am asbolutly not sure) it means that when I run something like:
python3 packet_sniffer.py
the packet_sniffer.py script (contained in the previous project) will be run using the Python 3 bynary and the dependencies that are into my venv folder. Is it correct?
If my reasoning is correct I have the following doubt:
What happen when I run it using Python 2 by
python packet_sniffer.py
I suppose that it is not using anymore the Python 3 version embedded into the venv folder of my project. And what dependencies of scapy am I using? where does it come from?
As you can see running with python instead python3 I am using Python 2 version:
root#kali:~# python --version
Python 2.7.17
root#kali:~# python3 --version
Python 3.7.5
If you create a virtual environment, and you then activate it, the python interpreter installed in this virtual environment will be run if you call any of these: python foo.py / python3 foo.py. There will be NO differences between calling python foo.py or python3 foo.py (if you installed python3 of course).
The lib folder will contain the associated dependencies that you install through pip in this virtual environment and when you use python interpreter through this virtual environment you will use the aforementioned dependencies
So from what I can understand it means that, using venv, every project have its own venv folder containing:
The bin folder: it contains the Python interpreter binary (in this specific case Python 3.7).
The lib folder: containing the dependencies that I have installed using pip3 (infact I installed scapy and scapy_http via pip3)
Using venv every project has its own virtual environment folder that you can name anything you want, containing yes the bin folder and the lib folder.
python virtual environments
The venv folder is a suggested standard for installing python virtual environments.
To use the virtual environment you must first activate it.
Note: Activate your python virtual environment prior to installing any packages required by your application.
from your command line execute:
source venv/bin/activate
python packet_sniffer.py
Note: You do not need to specify the specific version of python as it defaults to the version used to create the virtual environment.
PyCharm can be configured to utilize python virtual environments
https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html
If you have the virtual environment activated then everything you say about executing python3 is correct. However, all other commands are still available and will run from wherever they are located assuming they can be found by your shell. So your python command is probably running the system-level installed version of python.
If you want to know exactly where that python interpreter is running from:
python
>>> import sys
>>> print(sys.executable)
C:\Python27\python.exe
I want to use python 2.7 instead of python 3, which is used by default (note that I have them both installed on my computer already).
So I tried what I saw should be the right thing to do, that is:
python -m virtualenv my_env -p "\Program Files (x86)\Python27\pythonw.exe"
and I receive the following message:
Running virtualenv with interpreter \Program Files (x86)\Python27\pythonw.exe
That doesn't look so much like an error to me, but yet, no environment is created. Can someone help me with that?
In order to not alter the default python installation, I have a virtualenv set up that automatically runs on startup. I've also set up my profile so that unless a virtualenv is running, pip will not run. I've been using python2.x up to now, and have now installed python3 via homebrew. When I attempt to install a new package via pip3, I get the following error: Could not find an activated virtualenv (required).. However, when I check for the existence of a virtual env by checking the $VIRTUAL_ENV variable, it tells me that a virtual env is in fact running: -bash: /Users/me/virtualenvs/r: is a directory. Do I need to create separate instances of virtualenvs for each version of python? Why will one of my versions of python recognize the virtualenv, while the other will not?
All your virtualenvs are stored in a directory -- /Users/me/virtualenvs in your case. If you go there, you'll notice that it executes totally separate python interpreters in each virtualenv. For example, this is a freshly created virtualenv:
I'd imagine that running pip3 while on the python2.7 virtualenv wouldn't work for that reason.
It seems that there are two different kinds of virtualenvs, one of which is compatible with python2 and one of which is compatible with python3. I'm not sure whether there is a way to get one that is compatible with both, but I went ahead and created a new virtualenv using python 3 (python3 -m venv myPython3Env), and have been able to successfully use that.
I'm aware of how to use virtualenv for isolating Python dependencies in a long-running script, like a Flask or Twisted app. But I've been sort of puzzled about how you're supposed to go about this for a script intended to be invoked from the command line.
Suppose I wanted to make a CLI tool for interacting with some API, perhaps using Click or docopt. Obviously you don't want to have to source venv/bin/activate every time you want to use this tool. But I'd assume that it's still best to still use virtualenv to keep a clean environment even beyond development.
Sorry for the newbie question, but...what are you supposed to do to package up a script so it can be cleanly used in this manner? (I'm more used to RubyGems, and am still figuring out Pip and VirtualEnv.)
In general, if a package you've installed in a virtual env that provides binary command line script, say in ~/.virtualenv/bin/ you can symlink it into ~/bin/ (or wherever on your path you'd like to put local scripts).
There are a couple projects that aim to solve this issue:
pipsi the pip script installer -- amounts to doing the virtual env creation and symlinking for you
pipx pip for executable binaries
An excellent article on virtualenv by Dabapps would make it clear for you:
http://www.dabapps.com/blog/introduction-to-pip-and-virtualenv-python/
As for invoking it from a CLI script:
1. cd to your project root
2. env/bin/python your_main_file.py (Assuming your virtualenv is named env)
This way you don't need to source the virtualenv everytime.
Each virtualenv has it's own Python site_packages, builtin modles, and Python interpreter. So virtualenv is meant to be used at the project level, not at the "package by package" level. It isolates a collection of Python modules and possible dependencies. Each virtualenv has it's own location where pip will install packages. In theory, virtualenv should not be necessary, but in practice, it's nice to have a way to have different "environments" with different versions of Python modules and Python interpreters. I don't know if Ruby has something similar, that would allow you to have different "sets" of gems for different projects.
People that use straight virtualenv will add aliases to their .bashrc, for example:
alias workonawesomeproject="source ~/venv/awesomeproject/bin/activate"
They would activate the virtualenv with the alias
workonawesomeproject
To leave a virtualenv you use the command deactivate
An easier way to deal with virtualenvs is to use virtualenvwrapper
pip install virtualenvwrapper
Add these lines to your .bashrc (or other shell initialization file)
export WORKON_HOME=$HOME/venv # this directory is your choice
export PROJECT_HOME=$HOME/src # this directory is your choice
source /usr/local/bin/virtualenvwrapper.sh # leave this alone
If you just modified your .bashrc make sure to source it
source ~/.bashrc
Then to make a new virtualenv you simply run
mkvirtualenv awesomeproject
To use that virtualenv
workon awesomeproject
To deactivate that virtualenv
deactivate
Virtualenvwrapper Docs:
http://virtualenvwrapper.readthedocs.org/en/latest/install.html