Packj does not identify Python packages with 'extras'

[KyeRussell]

Describe the bug Python packages have the concept of 'extras'. As described by the Python packaging tutorial:

Extras are optional “variants” of a package, which may include additional dependencies, and thereby enable additional functionality from the package.

Packj does not parse out these 'extras' when reading in a requirements.txt file.

I am new to Packj so unsure if Packj goes as far as to resolve a package's dependencies. I assume that it doesn't?

If I'm right, one could definitely argue that Packj should instead be run against a 'flattened' set of Python requirements (where all transient dependencies are included at the top level), e.g. the requirements.txt resulting from 'compiling' a requirements.in in the pip-tools workflow. And if Packj does consider dependencies, it's obviously still best practice to run it against a resolved set of dependencies anyway. In this case though it might be worth explicitly noting (in the error output) that the given package can't be resolved by virtue of it containing an extra, instead of trying (and inherently always failing) to find it in PyPI.

However, at the very least it might be good to

To Reproduce Steps to reproduce the behavior:

1. Run Packj against the following dependency: Django[argon2]

   Output:

   ===============================================
   Auditing pypi package Django[argon2] (ver: latest)
   ===============================================
   [+] Fetching 'Django[argon2]' from pypi.....FAIL [package not found!]
   =============================================
   

Expected behavior One of:

• Django is considered without any of its dependencies (whether or not they are core dependencies or via an extra), if that is how Packj works for other packages
• Django (+ its 'extras') are considered
• A friendlier warning/error is given.

[ashishbijlani]

Thanks! We would love to receive code contributions from you to address this issue.