Menu
pip freeze shows packages YOU installed via pip (or pipenv if using that tool) command in a requirements format. Remark below that setuptools, pip, wheel are installed when pipenv shell creates my virtual envelope.
pip freeze is a very useful command, because it tells you which modules you've installed with pip install and the versions of these modules that you are currently have installed on your computer. In Python, there's a lot of things that may be incompatible, such as certain modules being incompatible with other modules.
Therefore, you should use pip list and pip freeze as follows: If you want to check a list of packages with various conditions, use pip list . If you want to create requirements. txt , use pip freeze .
As you have noticed, pip freeze doesn't capture the libraries specific to a directory but indeed all the package installed in the current environment (most likely the packages installed on your system or, if you are in a virtual environment without global access, those from that virtual environment).
According to https://github.com/pypa/pip/issues/4022, this is a bug resulting from Ubuntu providing incorrect metadata to pip. So, no there does not seem to be a good reason for this behaviour. I filed a follow-up bug with Ubuntu. https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1635463
To backup the previous answer, it should be safe to remove that line from your requirements.txt. Here is an example Make file stanza that safely freezes your package list (drop in your Makefile and run with make freeze):
freeze:
pip freeze | grep -v "pkg-resources" > requirements.txt
As for the part of your question "is it OK to remove this line?":
I have the same issue here developing on an ubuntu 16.04 with that very line in the requirements. When deploying on a debian 8.5 running "pip install -r requirements.txt" pip complains that pkg-resources is "not found" but there is a global package installed "python-pkg-resources" so the dependency should be satisfied. Same on ubuntu: The package exists there as well.
As stated here it seems to be some "implicitly installed package".
So: If you are on a Debian/Ubuntu having python-pkg-resources installed it should be safe to remove that line. I did so and everything is running fine. However since I am no expert on this you should keep in mind that this might lead to complications when deploying on another machine.
found this answer in this link: https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1635463
by: Louis Bouchard (louis) wrote on 2019-11-16:
It worked for me. But Iḿ not an expert so, if someone undestend it better, would be great if explained it.
Hello,
for what it's worth, the problem comes from the debianized version of virtualenv which uses a debundled version of pkg_resource which gets added into the virtualenv at creation time :
$ virtualenv .
Running virtualenv with interpreter /usr/bin/python2
New python executable in /home/caribou/git/quividi/test/bin/python2
Also creating executable in /home/caribou/git/quividi/test/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.
$ pip freeze
pkg-resources==0.0.0
Using the pip installed version of virtualenv can be a workable workaround :
$ sudo apt -y purge python3-virtualenv virtualenv tox
$ pip install virtualenv
$ virtualenv .
pip install virtualenv
Collecting virtualenv
Downloading https://files.pythonhosted.org/packages/c5/97/00dd42a0fc41e9016b23f07ec7f657f636cb672fad9cf72b80f8f65c6a46/virtualenv-16.7.7-py2.py3-none-any.whl (3.4MB)
100% |████████████████████████████████| 3.4MB 351kB/s
Installing collected packages: virtualenv
Successfully installed virtualenv-16.7.7
$ virtualenv .
New python executable in /home/caribou/git/quividi/test/bin/python
Installing setuptools, pip, wheel...
done.
$ source bin/activate
$ pip freeze
$
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