aboutcode-org / python-inspector

Inspect Python code and PyPI package manifests. Resolve Python dependencies.
22 stars 19 forks source link

Missing dependencies for Python 2.7 #62

Closed mnonnenmacher closed 2 years ago

mnonnenmacher commented 2 years ago

python-inspector is missing some dependencies when used with --python-version 27.

Test project used: https://github.com/spdx/tools-python/tree/a48022e65a8897d0e4f2e93d8e53695d2c13ea23

When running pip install with Python 2.7 on this project the following packages are installed:

Successfully installed isodate-0.6.1 ply-3.11 pyparsing-2.4.7 rdflib-5.0.0 six-1.16.0 spdx-tools-0.5.4

But running python-inspector --python-version 27 setup.py only returns:

[
  {
    "key": "ply",
    "package_name": "ply",
    "installed_version": "3.11",
    "dependencies": []
  },
  {
    "key": "rdflib",
    "package_name": "rdflib",
    "installed_version": "5.0.0",
    "dependencies": []
  },
  {
    "key": "six",
    "package_name": "six",
    "installed_version": "1.16.0",
    "dependencies": []
  }
]

So isodate-0.6.1 and pyparsing-2.4.7 are missing from the output.

pombredanne commented 2 years ago

Thanks for the report. Are you really still using this SPDX library with Python 2.7 in particular?

sschuberth commented 2 years ago

Are you really still using this SPDX library with Python 2.7 in particular?

ORT is not really making use of that library. We just use that library as a test project for ORT's functional analyzer tests.

pombredanne commented 2 years ago

@sschuberth ack. Fair enough. Python 2 is not the key issue, but rather that they do compute various arguments at install time The way to get these (without installing) will be a Python evaluation the provided values as they cannot be reliably parsed in this case. IMHO the best would be guard this with an --insecure CLI option. (NB: ORT behaviour prior to using python-inspector is what I would call "insecure" too, FWIW)

sschuberth commented 2 years ago

NB: ORT behaviour prior to using python-inspector is what I would call "insecure" too, FWIW

Yes, I guess we aim for correctness over security 😉

mnonnenmacher commented 2 years ago

I agree that having this as a command line option would be good, then the decision would be up to the user.

mnonnenmacher commented 2 years ago

I am closing this issue because with the new 0.7.0 release and the --analyze-setup-py-insecurely option the dependencies are now reported correctly.