pipdeptree icon indicating copy to clipboard operation
pipdeptree copied to clipboard

pipdeptree not able to detect exact version of the package

Open ConfuzedCoder opened this issue 4 years ago • 6 comments

Hi

I have installed argparse version 1.4.0 but pepdeptree shows a warning that tells, "Possibly conflicting dependency. - argparse [required: >=1.3.0, installed: 1.1]"

I have installed version 1.4.0 but it says the installed version is 1.1

Screenshot from 2021-01-13 16-12-21

ConfuzedCoder avatar Jan 13 '21 10:01 ConfuzedCoder

Internally pipdeptree just uses pip, so this is strange. My guess is that pipdeptree (2nd command) isn't using the same pip that's used to install argparse (1st command).

If you are on the latest pipdeptree ver. 2.0.0, you can quickly verify this by specifying the python interpreter as follows

    pipdeptree --python python3

naiquevin avatar Jan 13 '21 12:01 naiquevin

Thank you @naiquevin for helping me.

I specified a python interpreter but getting the same output.

Screenshot from 2021-01-13 20-02-06

ConfuzedCoder avatar Jan 13 '21 14:01 ConfuzedCoder

Can you please paste the output of misc/bin/pip freeze here?

naiquevin avatar Jan 13 '21 15:01 naiquevin

@naiquevin here it is.

backcall==0.2.0 cachetools==4.2.0 certifi==2020.12.5 cffi==1.14.4 chardet==4.0.0 dataclasses==0.8 decorator==4.4.2 df2gspread==1.0.4 google-api-core==1.24.1 google-api-python-client==1.6.7 google-auth==1.24.0 google-auth-oauthlib==0.4.2 google-cloud-bigquery==2.6.2 google-cloud-bigquery-storage==2.1.0 google-cloud-core==1.5.0 google-crc32c==1.1.0 google-resumable-media==1.2.0 googleapis-common-protos==1.52.0 grpcio==1.34.0 gspread==3.6.0 httplib2==0.18.1 idna==2.10 ipykernel==5.4.3 ipython==7.16.1 ipython-genutils==0.2.0 jedi==0.18.0 jupyter-client==6.1.11 jupyter-core==4.7.0 libcst==0.3.16 mypy-extensions==0.4.3 numpy==1.19.5 oauth2client==4.1.3 oauthlib==3.1.0 pandas==1.1.5 pandas-gbq==0.14.1 parso==0.8.1 pexpect==4.8.0 pickleshare==0.7.5 pipdeptree==2.0.0 pkg-resources==0.0.0 prompt-toolkit==3.0.10 proto-plus==1.13.0 protobuf==3.14.0 ptyprocess==0.7.0 pyarrow==2.0.0 pyasn1==0.4.8 pyasn1-modules==0.2.8 pycparser==2.20 pydata-google-auth==1.1.0 Pygments==2.7.4 PyMySQL==1.0.2 python-dateutil==2.8.1 pythonbq==0.2 pytz==2020.5 PyYAML==5.3.1 pyzmq==20.0.0 requests==2.25.1 requests-oauthlib==1.3.0 rsa==4.7 six==1.15.0 SQLAlchemy==1.3.22 tornado==6.1 tqdm==4.56.0 traitlets==4.3.3 typing-extensions==3.7.4.3 typing-inspect==0.6.0 uritemplate==3.0.1 urllib3==1.26.2 wcwidth==0.2.5

ConfuzedCoder avatar Jan 13 '21 18:01 ConfuzedCoder

@naiquevin any comment on the issue?

ConfuzedCoder avatar Jan 19 '21 04:01 ConfuzedCoder

I could reproduce this issue and I think I know what's happening here. So, argparse from the python stdlib is being used, which has __version__ = '1.1'. Even though the df2gspread package requires version > 1.3.0, the one from stdlib is shadowing it. See the output below.

(pdt-144) ➜  pipdeptree git:(master) ✗ python
Python 3.6.4 (default, Feb 24 2018, 12:40:17)
[GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import argparse
>>> argparse.__version__
'1.1'
>>> argparse.__file__
'/usr/local/lib/python3.6/argparse.py'
>>> ^D
(pdt-144) ➜  pipdeptree git:(master) ✗ grep '__version__' /usr/local/lib/python3.6/argparse.py
__version__ = '1.1'
(pdt-144) ➜  pipdeptree git:(master) ✗

The pypi page for argparse says,

As of Python >= 2.7 and >= 3.2, the argparse module is maintained within the Python standard library. For users who still need to support Python < 2.7 or < 3.2, it is also provided as a separate package, which tries to stay compatible with the module in the standard library, but also supports older Python versions.

One possibility is that on python version < 2.7 or < 3.2, the correct version gets installed. Haven't tried it though.

Also, IMO the df2gspread package should ideally be defining argparse as an optional dependency so that it can be installed only if required.

Honestly, I am not sure what would be a good way to fix this from pipdeptree's point of view, as it's the behaviour of pip and pipdeptree completely relies on pip for finding the package dependencies.

naiquevin avatar Jan 25 '21 17:01 naiquevin

No good solution here so closing this.

gaborbernat avatar Sep 05 '22 03:09 gaborbernat