Fix incomplete clean up of odd python requirements #5647
Conversation
|
I'm not sure how this fits in, but this PR tickled my memory. Poetry at least allows a space delimiter as well as a comma: #5363. I've also confirmed Poetry allows no delimiter: |
|
Aha! I had recently learnt that requirement format for Poetry is different than the standard, so I had assumed that we were not parsing those in the same way. But maybe we are? I will review this! |
deivid-rodriguez
force-pushed
the
deivid-rodriguez/python-requirement-cleanup
branch
from
953396f to
a82a8d8
Compare
In 45f5b77, we started handling odd python requirements, with multiple constraints not separated by colons. Native behavior is to ignore anything after the first requirement, yet we were only ignoring the first one. This was discovered though a CodeQL alert.
deivid-rodriguez
force-pushed
the
deivid-rodriguez/python-requirement-cleanup
branch
from
a82a8d8 to
4f4fd6f
Compare
deivid-rodriguez
deleted the
deivid-rodriguez/python-requirement-cleanup
branch
| context "with multiple operators after the first" do | ||
| let(:requirement_string) { ">=2.0<2.1<2.2" } | ||
| # Python ignores operators after the first! | ||
| it { is_expected.to eq(Gem::Requirement.new(">=2.0")) } |
There was a problem hiding this comment.
Curious why you added a new test case rather than modifying the existing test case from 45f5b77#diff-606e746adf06604fa9039dd903280cffd0c3ee1485e2d54ad5e13932279a019aR40-R44 ?
Is there a scenario you envision where it's useful to test 2 operators that wouldn't be caught by testing 3 operators?
There was a problem hiding this comment.
Normally I prefer adding separate specs over modifying existing ones, mostly because I don't want to lose any coverage and many times I don't feel I can tell for sure whether that would be the case if I modify the spec. I also think it makes patches more focused, although it normally introduces some duplication and overhead. In this case it would probably be fine to change the existing spec, although it would be a bit weird to only test three operators instead of two? I think testing both cases illustrates that there's a bit more complexity when handling more than two.
In 45f5b77, we started handling odd python requirements, with multiple constraints not separated by colons.
Native behavior is to ignore anything after the first requirement, yet we were only ignoring the first one.