Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recognize Python packages (wheels, eggs, various dist as archives or installed) #253

Closed
balusarakesh opened this issue Apr 13, 2016 · 20 comments

Comments

@balusarakesh
Copy link
Collaborator

scancode must be able to detect Python packages used by in a project by parsing files like setup.py, .whl files, .eggs files, requirements.txt or pip_requirements.txt.

@pombredanne pombredanne changed the title recognize python packages Recognize Python packages (wheels, eggs, various dist as archives or installed) Apr 18, 2016
pombredanne pushed a commit that referenced this issue Dec 6, 2016
pombredanne pushed a commit that referenced this issue Dec 6, 2016
Signed-off-by: Philippe Ombredanne <[email protected]>
pombredanne pushed a commit that referenced this issue Dec 6, 2016
pombredanne pushed a commit that referenced this issue Dec 6, 2016
Signed-off-by: Philippe Ombredanne <[email protected]>
pombredanne pushed a commit that referenced this issue Dec 6, 2016
Signed-off-by: Philippe Ombredanne <[email protected]>
pombredanne added a commit that referenced this issue Dec 6, 2016
licodeli pushed a commit that referenced this issue Jan 5, 2017
pombredanne added a commit that referenced this issue Jan 5, 2017
@sschuberth
Copy link
Collaborator

Just for the record, while PR #421 is thankfully merged, support for recognizing Python packages based on *requirements*.txt files is still missing.

@pombredanne
Copy link
Member

pombredanne commented Jan 6, 2017

@sschuberth indeed. There are several limitation in the current code.

  1. support for requirements is one: https://github.com/landscapeio/requirements-detector may be what the doctor ordered, may be together with pip proper used as a library and also many of the https://pypi.python.org/pypi?%3Aaction=search&submit=search&term=requirements

  2. support for parsing setup.py is somewhat weak too. These could be some pointers:

  1. Parsing actual packages as installed could likely benefit from code/functions existing in distutils, pip and setuptools

@pombredanne pombredanne modified the milestone: v2.0 Mar 24, 2017
@pombredanne
Copy link
Member

The basic is there. Addintional updates will be for post 2.0

@pombredanne pombredanne modified the milestones: v2.1, v2.0 Mar 24, 2017
@pombredanne pombredanne added this to the v2.1 milestone Jun 23, 2017
@jayfk
Copy link

jayfk commented Jul 13, 2017

Okay, this is now useable for requirements.txt, tox.ini and conda.yml (PyPi dependencies only).

I'm planning to add read-only setup.py support soon.

@pombredanne
Copy link
Member

@jayfk Thanks++
So I guess my approach will be to:

  1. for conda and tox files invoke with the proper filetypes. Check for exceptions and is_valid
  2. for req-like looking text files invoke with the proper filetypes. Check for exceptions and is_valid too. Since there are possibly more filename variety there, I will fish with a wide net and balk if this does not parse and only return errors when this is really a requirements*.txt files. I guess something similar to this: https://github.com/pyupio/pyup/blob/e6d2984efb42be8d195ac1f2c7e6a27505596fdc/pyup/bot.py#L486

@licodeli
Copy link
Contributor

Please refer to this: https://pythonhosted.org/pkginfo/distributions.html#introspecting-unpacked-source-distributions

Our goal is to report first installed Python packages, this is likely a job for pkg_info instead of dparse

licodeli pushed a commit that referenced this issue May 27, 2019
@licodeli
Copy link
Contributor

This can be another tool: https://pypi.org/project/wheel-inspect/

licodeli pushed a commit that referenced this issue May 29, 2019
licodeli pushed a commit that referenced this issue Jun 1, 2019
licodeli pushed a commit that referenced this issue Jun 3, 2019
licodeli pushed a commit that referenced this issue Jun 5, 2019
licodeli pushed a commit that referenced this issue Jun 9, 2019
licodeli pushed a commit that referenced this issue Jun 9, 2019
licodeli pushed a commit that referenced this issue Jun 11, 2019
licodeli pushed a commit that referenced this issue Jun 11, 2019
licodeli pushed a commit that referenced this issue Jun 12, 2019
@pombredanne
Copy link
Member

This is all done now and merged in develop.

pombredanne pushed a commit that referenced this issue Sep 8, 2022
Fixes #253

This patch contains these changes:

* Add 50+ new Ruby tests for method name/operator override matching.
* Unicode method names are now supported (#253).
* `=` method name postfixes are now supported.
* These operator overrides are now supported:
  `<`, `<=`, `!` `!@`, `~@`, `!`, `!=`, `!~`, `=~`
* The `<>` "operator" override is removed. It appears that this was
  a typo in the regular expression (`<=?>` should have been `<=>?`).

Syntax verified with https://docs.ruby-lang.org/en/2.7.0/syntax/methods_rdoc.html
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants