662 duplicates are not supported in requirements.txt when run with disable pip #749
Conversation
|
Thanks for the patch @mathbou! I'll review this today. |
…uirements.txt-when-run-with---disable-pip
…ents.txt-when-run-with---disable-pip
…ents.txt-when-run-with---disable-pip
…ents.txt-when-run-with---disable-pip
…ents.txt-when-run-with---disable-pip
|
It's been a while here, is there anything that prevent us to go further with this PR ? @woodruffw |
…ents.txt-when-run-with---disable-pip
Nope, I've just been delayed in reviews, sorry 😅. I'll do another pass on this today. (Thank you very much for keeping this PR alive and conflict-free!) |
|
@woodruffw I updated the changelog, feel free to change it if it's not clear enough |
| else: | ||
| # We have a duplicate requirement for the same package and the specifier matches | ||
| # As they would return the same result from the audit, there no need to yield it a second time. | ||
| continue |
There was a problem hiding this comment.
From CI: this line needs coverage!
There was a problem hiding this comment.
This is weird, coverage complains about this line only with py3.8 and 3.9, from 3.10 and above I get 100%.
There was a problem hiding this comment.
This is probably a manifestation of nedbat/coveragepy#198, which was ultimately resolved in 3.10+ via PEP 626: https://peps.python.org/pep-0626/
The two solutions here are either to drop the else: ... continue or add a coverage ignore comment.
…ents.txt-when-run-with---disable-pip
…ents.txt-when-run-with---disable-pip
…ents.txt-when-run-with---disable-pip
Recently, I run in the same problem described in #662. To avoid this, I propose a finer check for duplicates based on both name and specifier.
As stated in the issue, when the
--disable-pipflag is used, we could consider that a full requirement resolution has been made. Knowing that, as long as specifiers matches, having duplicates is not a problem. If they don't match, we raise an error like before.On the side, I also add a small fix for stdout/stderr reading in
pip_audit/_subprocess.py. I don't know if it's specific to windows, but the fact that a size was specified, I had the process hanging indefinitely.