Open tetsuo-cpp opened 2 years ago
re:
How do you feel about having this logic in pip-requirements-parser? I appreciate that this logic perhaps goes a bit beyond "parsing" but it'd be useful since not all editable requirements have an egg fragment.
@tetsuo-cpp This would be fine... note that there is related code to parse setup.py in https://github.com/nexB/scancode-toolkit/blob/1d575e8935654d6d71b1df42eb7dd3183ac76ca0/src/packagedcode/pypi_setup_py.py and that I have a un-yet-pushed branch where I extracted the "mostly correct" parsing code for setup.cfg and pyproject.toml from setuptools itself.
And FWIW, since you seem to fancy PyPI packages like we tend to, this has extensive support for many different package manifest and lockfile styles and formats https://github.com/nexB/scancode-toolkit/blob/1d575e8935654d6d71b1df42eb7dd3183ac76ca0/src/packagedcode/pypi.py (it also calls pip-requirements-parser).
I noticed another small difference between
pip-api
andpip-requirements-parser
which I'd like to bring up. At the moment,pip-requirements-parser
relies on an egg fragment being at the end of an editable install in order to infer its name/specifier. Otherwise, theEditableRequirement
'sreq
member is set toNone
.pip-api
has some special logic that checks whether the editable installation points to a directory. If so, it checks that directory for asetup.py
and attempts to parse the package name and version out of the file. You can find the relevant logic here.How do you feel about having this logic in
pip-requirements-parser
? I appreciate that this logic perhaps goes a bit beyond "parsing" but it'd be useful since not all editable requirements have an egg fragment.