fix: Resolve kserve with pip --dry-run instead of installing it - #6733
Conversation
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #6733 +/- ##
=======================================
Coverage 46.80% 46.80%
=======================================
Files 415 415
Lines 50395 50395
Branches 7214 7214
=======================================
Hits 23588 23588
Misses 25155 25155
Partials 1652 1652
*This pull request uses carry forward flags. Click here to find out more. Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
|
@ntkathole thanks for the review. Now that Worth noting the other five integration jobs pass here, including GitHub also reports this branch as BEHIND. Happy to merge master in if you'd like it current before merging, though I've left it alone since it's conflict-free and a merge commit would re-run everything for no change. |
test_install_kserve_with_feast installed kserve into the interpreter running the suite, with no isolation and no cleanup, so it mutated the environment every other test was using. Feast pins psutil==5.9.0 and kserve requires psutil>=5.9.6, so pip could not leave the installed version alone: it uninstalled psutil before reinstalling 5.9.8. The unit suite runs pytest -n 8 against one environment, so any test importing psutil in that window failed, including every test that shells out to the CLI, since feast.metrics imports it at module scope. That is how an unrelated docs PR got a red unit-test-python job on test_3rd_party_providers with ModuleNotFoundError: No module named 'psutil'. Being timing-dependent, it read as flake. kserve also pulled protobuf down to 4.25.x, which left the environment broken for the next run: the installed grpcio-health-checking ships protobuf 6.x gencode importing google.protobuf.runtime_version. The first run passed because collection imports precede the mid-run install; the second failed at collection. --dry-run performs the same resolution and still exits non-zero when the versions cannot be satisfied together, which is what the test guards against, without installing anything. Verified both directions: a clean resolution exits 0 and leaves psutil at 5.9.0 with kserve not importable, and 'pip install --dry-run kserve==0.15.2 psutil==5.9.0' exits 1 with conflicting dependencies. Also replaces the conflict assertion, which was inverted - it was only true when pip reported conflicts without an error, so a loud failure set it to False. The exit code was already doing the real work; it now carries pip's output for diagnosis. The full unit suite now passes twice in a row: 2529 passed, 20 skipped both times, with psutil and protobuf unchanged after the first. Closes feast-dev#6732 Signed-off-by: Larry Singleton <166439969+larrysingleton007@users.noreply.github.com>
ac910bc to
33a8e47
Compare
3 participants
What this PR does / why we need it
test_install_kserve_with_feastinstalls kserve into the interpreter running the unit suite, with no isolation and no cleanup, so it mutates the environment every other test is using.Feast pins
psutil==5.9.0and kserve 0.15.2 requirespsutil<6.0.0,>=5.9.6, so pip cannot leave the installed version in place — it uninstalls psutil, then installs 5.9.8:make test-python-unitrunspytest -n 8, so eight workers share one environment. Any test importing psutil during that window fails, including every test that shells out to the CLI, sincefeast/metrics.pyimports it at module scope. That is how an unrelated docs PR picked up a redunit-test-python (3.12, ubuntu-latest)ontest_3rd_party_providerswithModuleNotFoundError: No module named 'psutil'. Because it depends on worker timing, a re-run usually passes and it reads as flake.kserve also pulls protobuf down to 4.25.x, which leaves the environment broken for the next run: the installed
grpcio-health-checkingships protobuf 6.x generated code importinggoogle.protobuf.runtime_version. The first run passes, because collection imports precede the mid-run install; the second fails at collection.--dry-runperforms the same resolution and still exits non-zero when the versions cannot be satisfied together, which is what the test guards against, without installing anything.This also replaces the conflict assertion, which was inverted:
That is only true when pip reports conflicts without an error, so a run failing loudly set it to
False. Theexit_code == 0assertion was already doing the real work; it now carries pip's output for diagnosis.Which issue(s) this PR fixes
Closes #6732
Misc
Verified both directions, so the detection is unchanged rather than merely quieter:
Would install … psutil-5.9.8 …), and leaves psutil at 5.9.0 with kserve not importable afterwardspip install --dry-run kserve==0.15.2 psutil==5.9.0exits 1 withCannot install kserve==0.15.2 and psutil==5.9.0 because these package versions have conflicting dependenciesThe full unit suite now passes twice in a row — 2529 passed, 20 skipped both times, with psutil still 5.9.0 and protobuf still 6.33.6 after the first. Previously the second run produced 31 failures and 8 collection errors. The test also drops from about 13s to under 2s.
This needs a
kind/label, which I cannot add as an outside contributor.