CASMPET-7271: Remove requests dependencies from virtual environment #627
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On the latest vshasta run with the updated csm-testing RPM, it hit hit SSL failures and dependency warnings when trying to use the requests package. I determined that the problem was that even though we were using the system requests package, we also needed to use the system versions of its package dependencies. That will both resolve the dependency warnings and allow it to make requests using the system certificates.
This PR does the above, moving the dependent packages out of the virtual environment and adding them as RPM requirements. I verified that this fixes the problem on vex, and also tested it further on mug, to make sure there were no problems.
This PR also makes the RPM spec file slightly more concise by moving some of the repeated requirements lines into a separate include file. That makes no functional difference, but makes the SPEC file slightly less cluttered.