What's the difference between the virtualenv from apt-get and that from pip? Are they interchangeable?
apt-get install virtualenv
The following extra packages will be installed:
python-chardet-whl python-colorama-whl python-distlib-whl python-html5lib-whl python-pip-whl python-requests-whl
python-setuptools-whl python-six-whl python-urllib3-whl python3-virtualenv
The following NEW packages will be installed:
python-chardet-whl python-colorama-whl python-distlib-whl python-html5lib-whl python-pip-whl python-requests-whl
python-setuptools-whl python-six-whl python-urllib3-whl python3-virtualenv virtualenv
pip is used to download and install packages directly from PyPI. PyPI is hosted by Python Software Foundation. It is a specialized package manager that only deals with python packages. apt-get is used to download and install packages from Ubuntu repositories which are hosted by Canonical.
pip is a tool for installing packages from the Python Package Index. virtualenv is a tool for creating isolated Python environments containing their own copy of python , pip , and their own place to keep libraries installed from PyPI.
These are almost completely interchangeable, the difference being that virtualenv supports older python versions and has a few more minor unique features, while venv is in the standard library.
To create a virtual environment, go to your project's directory and run venv. If you are using Python 2, replace venv with virtualenv in the below commands. The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it env .
At a high-level apt
is something maintained by your system. Specifically anything in the debian family will use apt
to manage things like drivers, compilers, things that require lower-level integration.
This means for things like numpy
and scipy
that require system-level integration with FORTRAN libraries, including the pip
dependency won't actually work.
Some python packages that are tightly-linked with the system-level dependencies maintain apt
packages that simply give you the full package all at once without having to coordinate between the two. The minus is that because Canonical's review process is pretty meticulous (as it should be) you will be getting, 9/10 a less-recent version of the library you're trying to use.
So, in short: you will often require apt
packages to enable more recent pip
installs, and while the same python dependencies may be available via apt
, these libraries are typically much older and may not have required functionality.
A common workaround is to simply use the system dependencies from one of these packages rather than the full package. You can do this by use the build-deps
flag. A common example given below:
apt-get build-dep python-scipy
pip install scipy
Which will actually give you the most up-to-date version of scipy while working within your virtualenv.
apt
or apt-get
- installer debian similar distributions and install the packages in the directory /usr/lib/python2.7/dist-packages
.
pip install
- python package manager and install the packages in the directory /usr/local/lib/python2.7/dist-packages
Both directories are in the path of python that it is looking for modules import.
>>> import sys
>>> sys.path
['/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7']
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With