-
Notifications
You must be signed in to change notification settings - Fork 64
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
requirement: Implement --fix
for RequirementSource
#225
Conversation
@woodruffw @di This could be optimised to do all the fixes in-memory and then write the file out at the end but it doesn't fit the
What are your thoughts on these two points? |
Yeah, this sounds good to me. Our execution is probably overwhelmingly dominated by network round-trips and
@di should probably have the final say on this, but IMO we should skip on comment handling for the MVP. I do think we should ultimately preserve comments, but we might need to rethink the
Hmm, this is a good point. Maybe this suggests that we redesign our initial If we go the above route, we'll probably want to refactor def fix(self, fix_versions: Iterator[ResolvedFixVersion]):
with self.fix_transaction():
for fix in fix_versions:
self.fix_one(fix) ...where OTOH, that's a lot of complexity, and maybe |
Personally, I think this is ok. Our summary specifically states that we fixed X vulnerabilities out of Y packages (compared with the Z vulnerabilities found in the audit), which indicates that we will fix everything we can but we don't guarantee we can fix everything. At the moment, if the package update fails, we yield a But I don't think it's ok to partially apply a single fix to some requirements files but not others. |
How does this look? I've attempted to deal with the case where to fail to write to one of the requirements files (or some other error gets thrown). I start by copying all requirements files to temporary files, then attempt to rewrite the requirements files. If we're successful, the temporary files will automatically get cleaned up. If not, I restore the requirements files by copying the temporary files back to the original location. |
This overall structure looks good to me! This approach also looks good, and I think it's what we'll want to encapsulate with the "fix transaction" interfaces above. But that can be a task for a follow-up PR 🙂 |
Co-authored-by: William Woodruff <[email protected]>
I'm still working on getting this tested. Mocking out things so the tests don't mess around with the filesystem has been a bit of a pain.
Hmm, I'm not following. The way I see it, the "fix transaction" interface is only necessary if we're intending to roll back fixes for other vulnerabilities in the case that one of them failed. Is that what we want? The recovery scheme I'm using here is for when a single vulnerability exists in multiple requirements files and we didn't manage to fix it in all files (as opposed to rolling back successful fixes for vulnerabilities across all files because a vulnerability further down the list couldn't be fixed). |
Whoops, this was a misunderstanding on my part. Yeah, we don't need the "transaction" interface in this case. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM overall! I left some small nits that I can take care of.
There might be some useful fixtures for test isolation in https://github.com/di/pip-api/blob/dec3a5e30c911b794763483ed985960a6732a40e/tests/conftest.py you could use to improve this. |
Closes #214